InterceptorTSK

хмммм... а вот это уже интересно, благодарю! я попробую покопаться в исходниках, только их ещё нужно найти, я экспериментировал лет пять как назад, и попробую посмотреть на то что вы говорите, но это будет только летом, ещё раз благодарю! кто-то написал что тема "интересная", так я больше скажу - тема не то что бы интересная, а вообще то "краеугольная", т.е. определяющая если не всё, то почти всё

как вы в моём коде [исходниках] собираетесь куда то смотреть? на что смотреть? на отсутствующие блокировки? так я вам разу говорю - их в коде [исходниках] - нет ; но они появляются в скомпилированном коде - это же очевидно; так вот для интела компилятор нагораживает их сильно меньше, чем для арма; потому что процессоры так устроены, и соответственно и компиляторы так устроены; тогда на что вы собираетесь смотреть то? я понять не могу

о боже, я вроде бы пишу очевидное, а тут про v8 инструкции какие то; до которых мне как до фанаря; простейший код - именно простейший - центральный поток, который разгребают вспомогательные потоки; и всё всегда без [любых, каких либо] блокировок, потому что я не использую на уровне исходников [кода] блокирующиеся алгоритмы, я такое вообще никогда не пользую уже как лет десять оно мне не нужно; т.е. в алгоритмах и соответственно в коде - блокировок - нет; но кто тогда расставляет блокировки в уже скомпилированном коде?

да например обычный код, карячится поток с массивом, массив обслуживает временной интервал [пусть 1сек], массив оптимизирован, и пусть 1млн тиков, т.е. индексы массива - по сути временные метки [тики]; элементы массива - сообщения; и куча параллельных потоков раздербанивают этот массив мисаг как сабаки - обрабатывают и складывают в отдельные хипы; понятное дело [предельно очевидно] оно wait-free/lock-free, но чем больше потоков на арме - тем линейная производительность падает, у интела - не падает

@avp частично; и к сожалению арм не вывозит; многопоточный код - всегда работает как и ожидается, другое дело эээ, я уже не знаю как сказать) тут другое дело; интел всегда работает без проблем, потому что [почти] полностью предсказуем; а что бы заработал арм - всё нужно увешать абсолютно всё предсказуемыми берьерами, иначе оно не работает; но как только сие происходит - мгновенно падает линейная производительность [от кол-ва ядер], у интела падения почти нет [~2-5%]

ну что понятно, когда ничего не понятно?) допустим есть 100 инструкций, и они исполняются как попало, потому что "умненький" компилятор нагородит как хочет, ему же видите ли "виднее", и это пол-беды, потому что есть обработка инструкций процессором, и уже там всё нагороженное тоже перемусолится как захочет, но только не под интел - и это всего лишь значит, что компилятор напихает "синхронизаторов" на 100 инструкций - для интела сильно меньше, чем если оно будет компилироваться под арм; и это работает - везде, не важно ассемблер это или плюсики или что-то ещё, это первичное свойство процессоров

@HolyBlackCat суть в обратном, как в многопотоке не использовать ни атомики, ни volatile, и при этом, если подходить к коду аккуратно - интел позволяет [почти позволяет] без этого жить, а вот арм этого не позволит, всё утыкивается массово разнообразными "синхронизаторами" - в этом суть

@avp "Еще volatile запрещает компилятору переставлять в коде операции с ним (именно в этом смысле volatile используется с ассемблерными вставками)" - и не только в ассемблере, в дот-нете такой же принцип, всё то [почти всё] что перед volatile - не меняется как угодно, но! в интеле сам проц не позволяет [почти не имеет такой возможности] изменять последовательность инструкций, а значит лишних ограничивающих телодвижений компилятор под интел не нагородит, а вот на арм - нагородит по полной

чюдеса случаются - и это так) берёте 12 ядер недо-арма, а в многопоток вменяемо поиграть не получится, всё завязнет в тотальном оверхеде - это ли не чюдо чюдесное чюдесатое?

"И что, как на ARMе жить с такими перестановками?" строго однопоточно) справедливости ради интел тоже слегка меняет инструкции, но на это можно влиять, именно потому на интеле можно играть в многопоток, а на арме - нет, всё нужно тотально берьерами обвешивать, недопроц жеж

а чем поможет атомик, если проц в конвеере команды [инструкции] переставляет как хочет? особенно недо-проц, под архитектурым названием арм

нужно точное чтение [получение] не начала строки, а начала логического блока данных, обычно это 4Кб; так вот произвольный доступ к строкам - это кеш блоков по 4Кб, и метадата для этих блоков; весь текст [данные] - делятся на блоки по 4Кб, и для каждого такого блока смещение на начала строк - относительно начала блока; таким образом получится что-то типа 4Кб_блок_0 = { 6, 38, 258 }; 4Кб_блок_1 = { 62, 86, 126 }; индексация в данном случае привязана к жёсткозаданным размерам физических данных; читать нужно именно физическими блоками, и рыться нужно в физических блоках [метадата блоков]

@Reason "Ни в текстовом, ни в двоичном режиме данную задачу не решить, поскольку нет подходящих для этого функций" - а что такое "функция"? и почему её нет? любая функция не растёт на дереве, и не является абстракцией в вакууме, и обычно "функция" обращается к более "фундаментальным" функциям, чем она есть сама; рассмотрите то что вы рассматриваете с точки зрения именно "фундаментальных" функций; вы можете читать, можете писать, а больше ничего не можете, потому что ничего другого - нет; и всякое любое производное - на этом и строится, потому что строить производное - больше не на чем

@PRODIGY надо полагать что вы даже сценарий на это придумать не в состоянии? есть война и мир того самого лео толстого, вы читаете сей эпос, затем на каком то месте закрываете его нафиг, а завтра хотите продолжить чтение; а вы каким образом обозначите где либо место на котором вы остановились читать? а если это не банальная книшка, а нечто - к чему обращается иное нечто, и хочет хочет знать где строчки лежат, но не хочет вычитывать весь файл - потому что файл - большой; т.е. такие сценарии конечно же не существуют ага?

"Или вы теперь скажете, что даже читать файл нельзя?" почему нельзя? можно) только читайте этот файл с нужного места - а где начинается это нужное место чтения?

@PRODIGY вы совсем полностью на своей волне что ли? у автора даже русскими кириллическими буквами написано - "быстрый переход на начало новой строки"; какой строки? любой строки, любой n-ой строки; последовательное чтение кусками по 1Кб - быстрым доступом не является, опять по определению; где тут быстрый доступ? что бы добраться до строки - нужно из 1Гб последовательно читать и парсить например 500Мб? вам чем ассемблер поможет то?

и да, если всё так просто, так вы прям щас создайте файл строк в 1Гб))) и получите из этого файла 9756-ую строку, но весь файл не читайте, начало файла - не трогайте, вообще ничего не парсите) оно же вам не нужно? не нужно) ну вот и запросто и найдёте каким то волшебным способом где начинается 9756-ая строка в этом большом файле, а как ассемблером найдёте - то непременно сюда выложите результат - это же не проблема? вперёд!

конкретней на пальцах: есть файл строк размером в 1Гб, сколько там строк - вы не знаете, начала [позиции/смещения] каждой строки - вы не знаете, вычитайте из этого файла [не читая весь файл] например - 9756-ую строку

@PRODIGY задачу внимательно посмотрите, нужен произвольный доступ к n-ой строке; и этот доступ возможен тогда, когда вычитан весь файл, и распарсен; но если вычитан весь файл и распарсен - то это уже не произвольный доступ по-определению произвольного доступа; ну потому что весь файл вычитывается целиком - тогда где тут произвольный доступ то? вы реально не понимаете банальность) требуется вычитать n-ую строку из файла, но весь файл вычитывать - не требуется - таковы требования автора, не мои

@PRODIGY не путайте пожалуйста терминологию, иначе очень сложно что либо понимать; бинарный/двоичный - имеет разный смысл; почему так? не знаю, этот вопрос точно не ко мне, а к лингвистам; однако же суть от это не меняется; вы имеете ввиду двоичные операции над данными/кодом, однако же применительно к поиску - термин "бинарный" означает конкретный алгоритм, без указания на реализацию оного; т.е. "бинарный поиск" - это абстрактный алгоритм поиска [в упорядоченных сортированных данных]

и прекратите флудить, вы решаете неким "примитивным куском кода" некую иную задачу, но не ту что нужно, потому что в результате вашего "примитивного куска кода" массив байт не появляется, я уже не знаю что с вами делать, впрочем ничего не нужно делать, тут ничего не поможет

я не обозвал ваш "примитивный кусог кода" медленным, я назвал его низкокачественным, потому что когда всё упадёт - вы не знаете что с этим делать, и я в пятый раз пишу - вы читернули, потому что вы не решили этим вашим "примитивным куском кода" задачу кеширования

BinaryReader конечно же, и вы опять упираетесь? вам же написано - вы читернули, а кешем называется всё то, что хранит данные (на средней дистанции по времени) для дальнейшего использования, и для неоднократного (многократного) обращения к этим данным, и мне нужен именно кеш, там лежит ресурс, или же его части

факты таковы, когда вы вычитаете всю вашу брехню в кеш - вы проиграете, и вот это и есть ФАКТ, и получается так, что в данном случае BinaryReader - это самый быстрый способ, и это тоже - факт, и вы можете делать с этим что хотите, но на самом деле - нужно изначально взять и потестировать, а зачем вы (именно вы) всю эту бадягу развели - вот это как раз таки загадашно

а мне не нужны результаты, потому что это всё давно потестировано, и под задачу вычитывания в кеш - давно получен самый быстрый результат, но вы свято верите в то, что всё это взято с потолка - в этом и есть ваша главная критическая ошибка

на этом "базар" окончен, и вот это уже и есть слив, но не мой

да ничего вы не показали ахаха! потому что вы читернули, StreamReader вычитывает в кеш, и кеш нужен мне, а если он вам не нужен - это ничего не значит, вычитывайте весь этот ваш фуфел в кеш, и не читерите, но тогда вы проиграете

суть была в том, что вы заявили, что BinaryReader - это плохо, а как раз таки наоборот - даже из вашего недотеста видно же - что это весьма хорошо, тем более что BinaryReader позволяет наделать быстрых коротких кешей, и не свалиться при записи, и в лох тоже не улетит, итд итп

WriteAllBytes() - не рассматривается, это отдельная песня, вы BinaryReader обгоните - ну вы заявили - вот и обгоняйте

у вас типичный пример типичного низкокачественного кода, ну потому что вам выше написано - если вы вдруг не сможете писать на диск - вы получите тыкву, а от того как сирвак упал - вы получите не тыкву, а в тыкву - и это правильно, и теперь сделайте как положено, со всеми проверками - и вы проиграете, потому что ваш код - это абстракция в вакууме

фокус: насколько я помню у BinaryReader-а, вообще внутреннего буфера нет, и всё вычитывается во внешний указанный буфер изначально определённой длины, но это не точно (но крайне весьма вероятно)

"несколько порций низкокачественного кода" - обгоните низкокачественный код, или опять бла-бла-бла?

а автор кто? автор - это изначально задающий вопрос, или уже я? вы пишете под моим ответом, а не под авторским, а значит некое обсуждение изначального автора тут не уместно, и всего лишь предложен способ (потестированный способ), который позволяет делать многое, с собственными ресурсами, крутить/вертеть это всё как угодно, а если вас не устраивает - так не пользуйтесь, в чём проблема то? а если вас тесты не устраивают - так напишите свои, и ага, кое где спаны так и не завезли, такое бывает

выше написано - у вас правоты нет, и НЕ правоты тоже нет, потому что у вас НИЧЕГО НЕТ, и вам в четвёртый раз пишется - возьмите и потестируйте, а вы зачем то в какой то код полезли, а зачем? вам написано чего делать - а вы принципиально делаете с точностью "данаабарот", но зачем? тестами все интырнеты завалены, но вам какие то факты "подавай", и если вы тестировать не хотите, погуглите - тестов полно, потестируйте (в 15 раз - потестируйте - я уже пейсать не буду, я устал, извините) code-maze.com/create-byte-array-from-stream-in-csharp

файл-стрим оптимизирован внезапно[!] под файлы, а ресурс лежит в памяти ахаха! потому что образ (весь екзешник) - в памяти лежит)) а ресурс - в екзешнике, и вы можете прям щяс потестить (только вам это не нужно) как работает один тип ридеров, и другой тип ридеров, и перф весьма различается, но вы без тестов без ничего и никого как обычно упритесь в ворота и стойте на некоем "своём", которого у вас нет, и никогда не будет

нет никакого файла, потому что запускаемый образ (екзешник) - в оперативке, и все ресурсы в этом екзешнике - в памяти, а не на диске, и вычитываются ресурсы из памяти а не с диска, и ага - создаём большой буфер внутри BinaryReader, и враз вычитываем всё туда, одной операцией, и маленький буфер (4кб) здесь не нужен, потому что он медленно работает, и ага - ещё раз - тесты поищите, BinaryReader/BinaryWriter работают быстрее всего, а про лох - это хоть стой хоть падай, ну потому что ресурс-менеджер поделить ресурс на части - не сможет, а собственный кеш из набора массивов byte[] - годится

само время существования стрима (и поверх) BinaryReader-а - минимально, и сборщик мусора вряд ли сработает, впрочем вы даже можете запретить ему работу на это время, и как только вы вычитаете всё в нужный кеш (пусть это массив или набор массивов) по выходу из метода стрим и его потороха отправятся внибыте, и никакому сборщику мусора они мешать не будут, потому что уже легко задиспожены, и никаких хендлов нет (в случае с файл-стримом), и тд и тп

"Я вам показал" - вы ничего не показали, потому что файл-стрим использует внутренний буфер, и он обычно равен 4кб, в эти 4кб вычитывается в поток что-то, это что-то и пишется куда то дальше. И это работает медленней, чем конкретный BinaryReader/BinaryWriter, потому что они не используют внутренние буферы, но используют внешний. Можно сделать так, что внешний буфер (он же кеш) - вообще то сразу равен размеру файла - и туда враз всё и вычитать, а затем всё это враз и записать. Сие работает быстрее всего. Тестов - полно.

Вы издеваетесь? - нет, я всего лишь понимаю как что работает.

А вы не грубите. Когда вы начнёте писать файл куда либо - вы можете получить ексепшн. Причём внезапно и не предсказуемо. Массив байт - это кеш. Вычитываете сколько нужно байт в кеш, а затем записываете в файл. Но если оно не получается, то попробуйте записать в другое место. А байты у вас уже есть, они закешированы в массиве.

BinaryReader это самый быстрый ридер, без оверхедов. Во всех иных ридерах оверхедов буран.

Идём далее, можно вытаскивать нужные куски ресурсов, потому что стрим это позволяет. Перемещайте стрим-позишн и читайте нужное из стрима. Ресурс-менеджер такое не умеет, насколько я помню. Что бы взять и вычитать (например) половину ресурса, а не весь целиком. И тд и тп.

Разница в том, что не используется Resources, который является встроенным деплоем, например в VS. Проблем со встроенным деплоем (через Resources) много, а самые банальные - это то что ресурсы (через Resources) выколупываются через невменяемый враппер. А можно без этого враппера. Когда ресурсов мало (один-два-три), то проще запросить их напрямую, как выше и обозначено. И на это всё скомпилированный ресурс-менеджер и все его потроха (которые VS накомпилило) болтающиеся в исполняемом файлике - не нужны. Хватит и трёх строк, что бы выколупать ресурс. Три строки - выше. А, нет, там четыре строки.

Только тут проблемка есть. Такой словарь с жесточайшим ограничением по параметрам, коих двадцать параметров - строится две секунды. Это на 10000 элементов. Перебирается настолько много вариантов построения словаря, что вы даже себе не представляете насколько хорошо всё оптимизируется. Но на это нужно гигантское время. А две секунды на 10000 - это абсолютно гигантское время. Оно замечательно подходит для статических словарей. А в общем математическом смысле проблема построения почти-идеального словаря за разумное время - не решаема. Или же узкие реализации. Чюдес не бывает, и не будет.

Причём здесь хеш-функции? На любые хеш-функции всегда найдутся "плохие данные", которые всё переломают. Пишите любые хеш-функции - и это вас не спасёт. Спасёт прямое управление словарём. Например жёсткое ограничение на длину цепочек. А оно есть? Неа. :) У меня - есть. А у вас - нет. И уж тем более нет ничего, что "сигнализирует" атаку по словарю. Вообще ничего такого нет. А так то конечно "словарь общего назначения" очень хорош. :) Ну да ну да. И цепочки вообще то не нужны. Прямая адресация [опять с ручным управлением] с ограничением по смещениям спасёт. Что бы не терялась локальность.

Если вы сильно подумаете, то в цепочку можно впихнуть 10000 элементов, чисто паржать. Затем запросить Александровича, который там где то в конце цепочки. Коллизии всегда можно подобрать, ВСЕГДА. И ваш недосирвак ляжет. Это называется "прапердолинг" через хеш-таблицы. Которых у вас полно. И так как "у вас всё нормально" - то вас можно "пердолить" по полной программе. У вас хеш-таблицы общего назначения, вы упорно [или упорото] этого не понимаете. А ещё вы не понимаете банальность, хеш-таблица - непредсказуема. И банальность в том, что она непредсказуема не только для атакующего, НО И ДЛЯ ВАС.

Вы там "что-то" напейсали про какой то GetHashCode, и это детский сад какой. Ну нужено ещё и переопределение Equals вообще то. А если вы сильно подумаете, то нужен ещё и компаратор, которого НЕТ. Банальность: в словаре Александрович, Натанович, Оскарович. Понятное дело что Александрович - нужнее, чем все остальные. Но стандартная реализация словаря напихивает в цепочку всё это как попало. И до Александровича вы достучитесь в последнюю очередь. Пока вкрай не опухните пробегать всю цепочку - вот тогда достучитесь. Нормально? И что же "не так" со стандартным словарём ага? Вообще то всё не так.

Всё так со стандартным словарём. Потому что это словарь общего назначения. Но всё то что "общего назначения" - оно по определению имеет оверхед. И в данном случае оверхед гигантский. Любой узкозаточенный словарь работает гораздо быстрее. И перечислять все виды узкозаточенных словарей - это бессмыслица. Не здесь же. А если про оверхед стандартного словаря - так очевидно же. Это массив связных списков зачем то, это отсутствие прямого доступа по индексу, это отсутствие внутреннего хеширования, и прочих проблем вагон и телега.

Дот.нет - это же Майкрософт, а значит по-определению - никогда толком не доделано. Хорошо это или плохо? Ну с одной стороны - плохо. Как можно за 25 лет в базовую библиотеку так и не вкарячить нормальный набор разнообразных словарей? Оказывается можно. Майкрософт жеж. Этим всё сказано. Однако же те кто знают как накарячить вменяемые реализации - всегда выиграют у тех, кто не знает. Получается так, что "не-дописанное" - для кого то плохо, а кому то наоборот - хорошо. А в общем то - всем плевать. Ну работает оно как то, и работает. Кому нужно быстрее - всегда сделают быстрее, чем в "стандарте".

"Сами" пишем. Они из "ниоткуда" не возьмутся.