Не подскажите максимально быстрый способ перевода? Помню во времена доса на асме буквально из десятка байт был финт для этого дела, может помнит кто?
А то дельфовый IntToHex(n, 2) сожрал всю скорость, посмотрев сырки стало сразу понятно куда)

А вообще нужно из md5 массива байт строку собрать
если делать влоб

то 10млн раз выполняются около 6 сек, хотелось бы поделить это время на 2 или 3... к слову, если вместо IntToHex просто добавлять '00', то будет 2 сек. Пробовал вместо простой конкатенации заюзать TStringBuilder, но нынче, похоже менеджер памяти уже сам вполне справляется с этим хламом и с ним только на 1 сек дольше получается. Так же пробовал выделить память сразу под всю строку и мувами загонять на места, но получается тоже дольше... в общем проблема только в переводе в hex, остальное, похоже достаточно оптимально работает

-----
z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh

| Сообщение посчитали полезным:

SReg пишет:
тут же похерив всю "оптимизацию"(?), дёрнув SetLength
Да плевать на этот setlength, главное чисто конвертация. Я понял там вверхняя и нижняя часть байтов в качестве самостоятельных чисел, затем сравнение с 9-кой, если выше то делаем +7, в конце всем +0x30 и получается строка. Инструкций psrlb/psllb не сущ-ют почему-то, но разом все равно криво можно.
Вот если бы AVX2, то махом, но у меня проц старый, чисто AVX.
О, порядок 16 байтов черт знает какой, т.е. если 0xDEAD, то 00000000DEAD или DEAD0000.... надо. Хз, проще же таблицу сделать 0-255 / '00'-'FF' и всё.

| Сообщение посчитали полезным: Isaev

shellstorm, это не глупость, а объективный факт. Неповоротливость софта, написанного на С/C++? Ты либо шутишь, либо ничего о нем не знаешь. Да, ща бы писать операционные системы на неповоротливом языке, млять. Давно такой херни не читал

-----
Харе курить веники и нюхать клей, к вам едет из Америки бог Шива, и он еврей.

| Сообщение посчитали полезным:

Crawler пишет: это не глупость, а объективный факт.

объективный факт в том, что сишка это язык общего назначения, на котором написаны некоторые операционные системы, а у тебя глупость. где я писал о неповоротливости, если речь была о решении архитектурных проблем сишки? чем условный rust или delphi неповоротлевей сишки, совсем наркоман? учи уроки и не путай язык с реализацией компилятора. например билдер сишка, но драйвера на нем особо не попишешь, такая реализация, но несмотря на это std-11. именно, сейчас бы писать о языках не имея о них представления.

| Сообщение посчитали полезным:

Возвращаясь к сабж, не верю, инттухекс нормальная(кроме purepascal-версии).
Вот это:


На это какбы:

Для начала. 16 или 8 нужно ставить для 8 байтов - не помню. Вместо 16(конвертаций) + 15(сложений) т.е. 31(!) пинка менеджеру памяти - должно стать 3.

| Сообщение посчитали полезным:

bizkitlimp пишет:
Хз, проще же таблицу сделать
кстати да, вариант))) Обгонит, наверное, byte2hex() надо попробовать
хотя она очень даже не плоха!

-----
z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh

| Сообщение посчитали полезным:

Плоха.
Вариант с таблицей 0..F тут уже был, он наиболее прост и понятен,
но он не лучший.

Хотя смотря для чего. Мне тот вариант тоже нравится.

Добавлено спустя 13 минут
Crawler пишет:
Давно такой херни не читал

Да уж.
Если на асме использовать конвенции при вызовах, а не аргументы в регистрах,
то программа почти ничем не будет отличаться от транслированной с Си.

Добавлено спустя 56 минут
Вообще, если сабжевый вопрос и не применим напрямую к заявленной цели со всякими хешами,
то уж для написания чего-то вроде хекс-редактора применим вполне.
Там крайне важно очень быстрое преобразование bin->hex.

| Сообщение посчитали полезным: Crawler

dosprog пишет:
Вообще, если сабжевый вопрос и не применим напрямую к заявленной цели со всякими хешами,
то уж для написания чего-то вроде хекс-редактора применим вполне.
Там применимо всё вообще, всё что в голову взбредет, будет в нех редакторе работать одинаково и разницы не почувствуешь. Все эти способы развивания гиперскоростей на гиперкочках как раз и дают драматическую разницу только при брутфорсе чего-либо. Когда в каком-нибудь простеньком алгоритме распихиваешь сколько можешь промежуточные значения по регистрам и он 48 бит перебирает пару суток, а не недель. Потому и вопрос нафига козе баян, если во всём этом добре потом еще коллизии искать предстоит. А в утилитарных задачах 5мс от 15мс на глаз отличить нельзя.

-----
2 оттенка серого

| Сообщение посчитали полезным:

f13nd пишет:
Там применимо всё вообще, всё что в голову взбредет, будет в нех редакторе работать одинаково и разницы не почувствуешь.

Нет. Скорость прокрутки текста будет говённая.

Кстати, разница между hiew и qview чувствовалась на 386-х машинах.
Hiew был тяжеловат.

f13nd пишет:
А в утилитарных задачах 5мс от 15мс на глаз отличить нельзя.

На глаз и не отличают.
Такие различия фиксируются уже на уровне подсознания.



| Сообщение посчитали полезным:

dosprog пишет: Если на асме использовать конвенции при вызовах, а не аргументы в регистрах

ты не получишь результат который мог выдать профи того времени на ассемблере и с каких пор трансляция стала бесплатной?

| Сообщение посчитали полезным:

dosprog пишет:
Нет. Скорость прокрутки текста будет говённая.
--> Link <--

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

-----
2 оттенка серого

| Сообщение посчитали полезным:

dosprog пишет:
Вариант с таблицей 0..F тут уже был, он наиболее прост и понятен,
но он не лучший.
Как ни странно, по скорости он действительно лучший. Причем именно с вариантом типа mov al,[table+eax]
Красивый вариант от Зубкова и компактный вариант с табличкой и XLAT по скорости проигрывают.

| Сообщение посчитали полезным:

f13nd пишет:
Один из лучших (а может быть лучший) нех редактор

) Ты только не смешы, не надо.

f13nd пишет:
На 386м его запускать не пробовал

)) Попробуй, чо

ManHunter пишет:
Красивый вариант от Зубкова и компактный вариант с табличкой и XLAT по скорости проигрывают.

Ну, у меня в ходу оба варианта (кроме описанного в зубковском опусе)



| Сообщение посчитали полезным:

dosprog пишет:
)) Попробуй, чо
Пытались, найдя такой капролит в самом дальнем углу склада списанной техники. Спаяли VGA-CGA переходник, нашли проектор, который согласился на разрешении че-то типа 200х300 работать, но сама материнка работать отказалась. Поэтому мое знакомство с легендой не состоялось.

dosprog пишет:
) Ты только не смешы, не надо. Я не знаю какой редактор для 386 проца лучше. После долгого и мучительного поиска инструмента для работы я пришел к этому вот инструменту.

-----
2 оттенка серого

| Сообщение посчитали полезным:

shellstorm пишет:
учи уроки
shellstorm пишет:
совсем наркоман

Бомбануло, поэтому переходишь на личности? Чувствую, диалога с тобой не получится. Попрошу в дальнейшем не допускать таких оскорблений.

Окей, окей, давай возьмём/напишем две идентичных программы из любой прикладной или системной области (раз уж ты говоришь о назначении) и проверим, что быстрее будет работать - программа на Си или на Делфи. Ты сольёшься с этого теста, гарантирую, потому что современные Си-компиляторы настолько великолепно оптимизируют код, что если человек, который его писал, не совсем дурак, он будет быстрее чего угодно, за исключением программы, *написанной на чистом ассемблере абсолютным гением.


shellstorm пишет:
где я писал о неповоротливости

Вот здесь?

shellstorm пишет:
на момент его создания его хейтили за прожорливость и неповоротливость готового софта

Просто без комментариев.

-----
Харе курить веники и нюхать клей, к вам едет из Америки бог Шива, и он еврей.

| Сообщение посчитали полезным:

Crawler пишет: Бомбануло, поэтому переходишь на личности?

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

Crawler пишет: Вот здесь?

Ключевое слово - на момент создания, если ты, додик, не знал, на момент создания и windows хейтили за слоупочность. Первые версии компилятора состояли из набора утилит из-за ограничения памяти и даже в современном си остались некоторые рудименты, разделение сборки на этапе были необходимы из-за ограничения памяти, и из-за этого код выдавался усредненный, и раздельная сборка это тоже из той эпохи, на тот момент качественней писали на ассемблере, память на тот момент была дорогой, и она сама по себе была ограниченной, даже за большие деньги нельзя было поставить 100500 гигабайт, большие исходники невозможно было оттранслировать, авторам пришлось писать утилиту для вырезания отдельных функций и сборки таких кусков. Стандарту класть на систему, это язык общего назначения, который можно использовать для написания системы, в зависимости от реализации компилятора, паскаль с фронтедом gcc внезапно генерирует такой же код, как и для сишки, это раз, второе, в стандарте не оговариваются частности, там только требования, допустим сортировка должна выполняться с такой-то сложностью, любой адекватный создатель компилятора обязан выполнять требование, даже если у него есть лучше алгоритм. Но клопы не видят разницы между языком и реализацией языка, главный критерий, это полнота языка, возможность работать напрямую с памятью (сырые указатели), возможность компиляции в нативный код.
LLVM усреднил реализации языков, а в анализе ast многие дадут фору сишке. Хотя о чем я, ты все равно ничего не поймешь.

| Сообщение посчитали полезным:

bizkitlimp

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

Crawler

Последнее обсуждение абсолютно не адекватно. Это спор про какой язык/компилер лучше, но всё зависит от конкретного человека, который реализует. Для обычных приложений данная оптимизация смысла не имеет, потоки почти всё время спят в ядре, ожидая события. Но есть задачи, где оптимизация решает всё и там скрипт полностью бесполезен. Про его оптимизатор говорят люди, далёкие от реальной оптимизации. Как бы не менялся говяный выхлоп компилера, он считается годным, без причин и обоснований, кучи системных манов по оптимизации конечно же читать не нужно

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет: Это спор про какой язык/компилер лучше

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

| Сообщение посчитали полезным:

shellstorm

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

Что бы опираться на реальные факты, а не на какие то косяки с гуем и прочую чепуху.

Результат предсказуем.

-----
vx

| Сообщение посчитали полезным:

difexacaw
На AVX2 20 инструкций должно выйти в теории для 16 байт:

Надо поискать штуку, которая хотя бы эмулирует, SDE кажется, вслепую не осилю.
SSE на насме максимум могу:

Батник:
По замерам (буффер предопределен и закеширован) - 25 тактов. Но это неважно, в IntToHex-е динамические строки и в purepascal-версии дополнительный динамический массив используется в конвертации. Вот из-за этого всё и тормозит.

| Сообщение посчитали полезным:

bizkitlimp

Вы реально знаете все эти наборы, что можите свободно их кодить o_0 ?

Что то сомневаюсь, это походу выхлоп компилера. Такое месево слишком сложно реализовать даже зная.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет: Имхо все эти заявления про скриптовый оптимизатор - фейк. Давайте так, покажите пример даже для данной задачи, что скрипт быстрее асм и что я не смогу его выхлоп оптимизировать; снимем профайл.

Легко, chrome быстрее твоего асм кода, ты его просто на ассемблере не напишешь, а измерять качество оптимизатора на hello word это что-то из разряда специальной олимпиады, но можешь начинать оптимизировать. Подобные утилиты в 99,9% попросту незачем оптимизировать, это очень редкий кейс, в моей практике проседание скорости наблюдал по большей части из-за неверно выбранного алгоритма, а вовсе не из-за того, что компилятор плохо оптимизирует, если хочется обсудить именно варианты оптимизаций, создай тему в оффтопе и обсудим, я исходники gcc два года задротил, есть что сказать.

| Сообщение посчитали полезным:

shellstorm

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

> измерять качество оптимизатора на hello word

Это не выхлоп компилера, а импортируемый осевой интерфейс. Нас же интересует выходной код компилера, а не осевые функции, не нужно вводить в заблуждение

> если хочется обсудить именно варианты оптимизаций, создай тему в оффтопе и обсудим

Последняя моя тема и была по оптимизации и компилер там вообще не при делах, алгоритм определяет профайл. Решение я нашёл, но это совсем иная тема.

Я же говорю про оптимизацию компиляторного кода. Нэйтив компилер генерит чистый код, так например собирается ядро. Там нет понятий компиляторных оптимизаций.

-----
vx

| Сообщение посчитали полезным:

difexacaw
Да там всё автоматом запоминается со временем, когда перечитываешь доки, видишь как в дебаггере регистры меняются. Просто кодишь на асме мини-алгоритмы. shuffling только разный в pshufb / pshuflw / pshufd там везде по-разному imm8 интерпретируется, его вот вечно приходится перечитывать как именно закодить для определенной инструкции.

| Сообщение посчитали полезным: difexacaw

difexacaw пишет: Вы приводите в пример какое то приложение, это никакого отношения к профайлу не имеет.

Как раз на большом софте оптимизатор важен и наиболее заметен, на 100-строчниках делают замеры только клопы, касательно chrome, там неплохой пример оптимизации, вместо вылизывания какой-то условной сортировки, люди обратили внимания как грузит процессор один из слоев рендера, отключив его, сразу получился большой прирост скорости, такая же родовая болезнь у electron'a, после патча VSCode стал гораздо меньше жрать памяти и грузить процессор.

difexacaw пишет: Там нет понятий компиляторных оптимизаций.

Учитывая, что сейчас даже для микроконтроллеров стали писать прошивки на плюсах или вовсе питоне с нодой, понятий оптимизации более чем достаточно, тем более основная часть ядра написана на си. Компилятор орудует правила, которые составляли неглупые люди, возьмем твой любимый пюре васик и если ты сделаешь аналог, заложив свои правила оптимизации, это будет оптимизирующий васик индия клерка и который в некоторых случаях, если конечно оптимизатор адекватно написан, он будет выдавать выхлоп лучше самого индия,и который будет вставлять графы еще на этапе трансляции и нагибать всех ав вендоров в последний, окончательный раз.
Очень мало задач где требуется вылизывание каждого байта, тем более для современных процессоров это делать сложно и еще сложнее когда актуальных версий процессоров много. Но кто считает себя бессмертным или мозоли на руках не мешают жить, те могут чистить ir выхлоп LLVM, он прекрасно парсится.

| Сообщение посчитали полезным:

shellstorm

Покажите на реальном примере, повторяю вопрос.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет: Покажите на реальном примере, повторяю вопрос.

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

| Сообщение посчитали полезным:

shellstorm

Диз хрома это дичайший ппц. Часть его написана вручную на асм. Это естественно что вы пример реальный не можете привести, просто потому что никакой оптимизации не существует, есть качество генерации кода, но это не может называться оптимизацией, увы.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет: оптимизации не существует

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

| Сообщение посчитали полезным:

shellstorm

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

-----
vx

| Сообщение посчитали полезным:

shellstorm пишет:
на момент создания и windows хейтили за слоупочность
На момент создания Windows была оболочкой над MS-DOS, лол. На момент создания много что хэйтили за слоупочность. По-вашему, это связано с языком, а не с реализацией?

shellstorm пишет:
LLVM усреднил реализации языков, а в анализе ast многие дадут фору сишке.

Это всё бессодержательный пиздёж, я пока не увидел ни одного конкретного доказательства в виде конкретных замеров времени выполнения.

-----
Харе курить веники и нюхать клей, к вам едет из Америки бог Шива, и он еврей.

| Сообщение посчитали полезным: