Сейчас на форуме: jinoweb (+6 невидимых)

 [email protected] —› Программирование —› ByteToHex
<< . 1 . 2 . 3 . 4 . 5 . >>
Посл.ответ Сообщение


Ранг: 756.3 (! !), 113thx
Активность: 0.610.05
Статус: Участник
Student

Создано: 07 июля 2018 22:06 · Поправил: Isaev
· Личное сообщение · #1

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

А вообще нужно из md5 массива байт строку собрать
если делать влоб
Code:
  1. s:='';
  2. for i:=0 to 15 do
  3.   s:=s+IntToHex(Digest[i], 2);

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

-----
z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh




Ранг: 15.8 (новичок), 3thx
Активность: 0.030.01
Статус: Участник

Создано: 09 июля 2018 19:48 · Поправил: bizkitlimp
· Личное сообщение · #2

SReg пишет:
тут же похерив всю "оптимизацию"(?), дёрнув SetLength

Да плевать на этот setlength, главное чисто конвертация. Я понял там вверхняя и нижняя часть байтов в качестве самостоятельных чисел, затем сравнение с 9-кой, если выше то делаем +7, в конце всем +0x30 и получается строка. Инструкций psrlb/psllb не сущ-ют почему-то, но разом все равно криво можно.
Code:
  1. procedure ByteToHexExW(const Source:PByte;const Buffer:PWideChar);
  2. asm
  3.   movdqu    xmm0,[rcx]
  4.   pshufb    xmm0,dqword ptr [@@shuffle]
  5.   movdqa    xmm5,xmm0
  6.   pand      xmm0,dqword ptr [@@F0]   //leave high
  7.   pand      xmm5,dqword ptr [@@0F]   //leave low
  8.   palignr   xmm0,xmm0,1              //shifting bytes by 4 to convert into low...
  9.   psrlw     xmm0,4
  10.   palignr   xmm0,xmm0,15
  11.   pmovzxbw  xmm4,xmm0                //rearranging to match string output order...
  12.   pmovzxbw  xmm3,xmm5
  13.   psllw     xmm3,8
  14.   por       xmm4,xmm3
  15.   pxor      xmm3,xmm3
  16.   punpckhbw xmm0,xmm3
  17.   punpckhbw xmm5,xmm3
  18.   psllw     xmm5,8
  19.   por       xmm5,xmm0
  20.   pxor      xmm3,xmm3                //converting first 16 values into chars...
  21.   movdqa    xmm0,xmm4
  22.   pcmpgtb   xmm0,dqword ptr [@@09]   //if value > 0x09 then 0xFF
  23.   pblendvb  xmm3,xmm4,xmm0           //blend 0xFF
  24.   paddb     xmm3,dqword ptr [@@07]   //add +7 to blent
  25.   pblendvb  xmm4,xmm3,xmm0           //blend 0xFF back
  26.   paddb     xmm4,dqword ptr [@@30]   //make chars
  27.   pxor      xmm3,xmm3                //converting second 16 values into chars...
  28.   movdqa    xmm0,xmm5
  29.   pcmpgtb   xmm0,dqword ptr [@@09]   //if value > 0x09 then 0xFF
  30.   pblendvb  xmm3,xmm5,xmm0           //blend 0xFF
  31.   paddb     xmm3,dqword ptr [@@07]   //add +7 to blent
  32.   pblendvb  xmm5,xmm3,xmm0           //blend 0xFF back
  33.   paddb     xmm5,dqword ptr [@@30]   //make chars
  34.   pmovzxbw  xmm0,xmm4                //unpacking into WideChars
  35.   psrldq    xmm4,8                   //unpacking into WideChars
  36.   pmovzxbw  xmm1,xmm4                //unpacking into WideChars
  37.   pmovzxbw  xmm2,xmm5                //unpacking into WideChars
  38.   psrldq    xmm5,8                   //unpacking into WideChars
  39.   pmovzxbw  xmm3,xmm5                //unpacking into WideChars
  40.   movdqu    [rdx+$00],xmm0
  41.   movdqu    [rdx+$10],xmm1
  42.   movdqu    [rdx+$20],xmm2
  43.   movdqu    [rdx+$30],xmm3
  44.   ret
  45.  
  46.   .ALIGN 16
  47. @@shuffle: dq $0001020304050607, $08090A0B0C0D0E0F
  48. @@F0:      dq $F0F0F0F0F0F0F0F0, $F0F0F0F0F0F0F0F0
  49. @@0F:      dq $0F0F0F0F0F0F0F0F, $0F0F0F0F0F0F0F0F
  50. @@09:      dq $0909090909090909, $0909090909090909
  51. @@07:      dq $0707070707070707, $0707070707070707
  52. @@30:      dq $3030303030303030, $3030303030303030
  53. end;
Вот если бы AVX2, то махом, но у меня проц старый, чисто AVX.
О, порядок 16 байтов черт знает какой, т.е. если 0xDEAD, то 00000000DEAD или DEAD0000.... надо. Хз, проще же таблицу сделать 0-255 / '00'-'FF' и всё.

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


Ранг: 216.9 (наставник), 85thx
Активность: 0.310.15
Статус: Участник
X-Literator

Создано: 09 июля 2018 20:11
· Личное сообщение · #3

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

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




Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 09 июля 2018 20:27
· Личное сообщение · #4

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

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



Ранг: 15.8 (новичок), 3thx
Активность: 0.030.01
Статус: Участник

Создано: 09 июля 2018 21:16 · Поправил: bizkitlimp
· Личное сообщение · #5

Возвращаясь к сабж, не верю, инттухекс нормальная(кроме purepascal-версии).
Вот это:
Code:
  1. s:='';
  2. for i:=0 to 15 do
  3.   s:=s+IntToHex(Digest[i], 2);


На это какбы:
Code:
  1. s:=IntToHex(PInt64(@Digest[0])^, 16) + IntToHex(PInt64(@Digest[8])^, 16);

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




Ранг: 756.3 (! !), 113thx
Активность: 0.610.05
Статус: Участник
Student

Создано: 09 июля 2018 23:01
· Личное сообщение · #6

bizkitlimp пишет:
Хз, проще же таблицу сделать

кстати да, вариант))) Обгонит, наверное, byte2hex() надо попробовать
хотя она очень даже не плоха!

-----
z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh




Ранг: 431.7 (мудрец), 390thx
Активность: 0.730.32
Статус: Участник

Создано: 10 июля 2018 01:44 · Поправил: dosprog
· Личное сообщение · #7

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

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

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

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

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

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


Ранг: 271.4 (наставник), 331thx
Активность: 0.321.49
Статус: Участник

Создано: 10 июля 2018 03:59 · Поправил: f13nd
· Личное сообщение · #8

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

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

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




Ранг: 431.7 (мудрец), 390thx
Активность: 0.730.32
Статус: Участник

Создано: 10 июля 2018 09:06 · Поправил: dosprog
· Личное сообщение · #9

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

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

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

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

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





Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 10 июля 2018 10:06
· Личное сообщение · #10

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

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




Ранг: 271.4 (наставник), 331thx
Активность: 0.321.49
Статус: Участник

Создано: 10 июля 2018 10:47 · Поправил: f13nd
· Личное сообщение · #11

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

--> Link <--

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

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





Ранг: 104.9 (ветеран), 47thx
Активность: 0.040.02
Статус: Участник

Создано: 10 июля 2018 11:08
· Личное сообщение · #12

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

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



Ранг: 431.7 (мудрец), 390thx
Активность: 0.730.32
Статус: Участник

Создано: 10 июля 2018 11:26 · Поправил: dosprog
· Личное сообщение · #13

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


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

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

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

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

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






Ранг: 271.4 (наставник), 331thx
Активность: 0.321.49
Статус: Участник

Создано: 10 июля 2018 11:37
· Личное сообщение · #14

dosprog пишет:
)) Попробуй, чо

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

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

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





Ранг: 216.9 (наставник), 85thx
Активность: 0.310.15
Статус: Участник
X-Literator

Создано: 10 июля 2018 13:21 · Поправил: Crawler
· Личное сообщение · #15

shellstorm пишет:
учи уроки

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


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

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


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


Вот здесь?

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


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

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




Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 10 июля 2018 14:46
· Личное сообщение · #16

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

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

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

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 10 июля 2018 18:49 · Поправил: difexacaw
· Личное сообщение · #17

bizkitlimp

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

Crawler

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

-----
vx




Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 10 июля 2018 20:03
· Личное сообщение · #18

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

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 10 июля 2018 20:12
· Личное сообщение · #19

shellstorm

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

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

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

-----
vx




Ранг: 15.8 (новичок), 3thx
Активность: 0.030.01
Статус: Участник

Создано: 10 июля 2018 20:22 · Поправил: bizkitlimp
· Личное сообщение · #20

difexacaw
На AVX2 20 инструкций должно выйти в теории для 16 байт:
Code:
  1.          vpmovzxbw        ymm0,[rcx]
  2.          vpsrlw   ymm1,ymm0,4
  3.          vpsllw   ymm0,ymm0,12
  4.          vpsrlw   ymm0,ymm0,4
  5.          vpor       ymm1,ymm0,ymm1
  6.          vpshuflw    ymm1,ymm1,$1B
  7.          vpshufhw    ymm1,ymm1,$1B
  8.          vpcmpgtb         ymm0,ymm1,[Bytes09]
  9.          vpblendvb        ymm2,ymm1,ymm0
  10.          vpaddb   ymm2,ymm2,[Bytes07]
  11.          vpblendvb        ymm1,ymm2,ymm0
  12.          vpaddb   ymm1,ymm1,[Bytes30]
  13.          vpxor     ymm2,ymm2
  14.          ;??
  15.          ;??
  16.          ;??
  17.          ;vmovdqu [rdx+0x00],ymm?
  18.          ;vmovdqu [rdx+0x20],ymm?
  19.          vzeroupper
  20.          ret

Надо поискать штуку, которая хотя бы эмулирует, SDE кажется, вслепую не осилю.
SSE на насме максимум могу:
Code:
  1. section .data
  2.  
  3. ALIGN 16 
  4. BytesF0 dq 0xF0F0F0F0F0F0F0F0, 0xF0F0F0F0F0F0F0F0
  5. Bytes0F dq 0x0F0F0F0F0F0F0F0F, 0x0F0F0F0F0F0F0F0F
  6. Bytes09 dq 0x0909090909090909, 0x0909090909090909
  7. Bytes07 dq 0x0707070707070707, 0x0707070707070707
  8. Bytes30 dq 0x3030303030303030, 0x3030303030303030
  9.  
  10. section .code
  11.  
  12. ALIGN 16 
  13. SSE42_16BytesToHex: ;(src) PBYTE Source -> rcx, (dest) LPWSTR Buffer -> rdx
  14.          movdqu   xmm0,[rcx]
  15.          movdqa   xmm5,xmm0
  16.          pand       xmm0,[BytesF0]   ;keep high
  17.          pand       xmm5,[Bytes0F]   ;keep low
  18.          ;shifting bytes by 4 to convert high into low...
  19.          palignr          xmm0,xmm0,1                    
  20.          psrlw     xmm0,4
  21.          palignr          xmm0,xmm0,15
  22.          ;rearranging to match string output order...
  23.          pmovzxbw         xmm4,xmm0                              
  24.          pmovzxbw         xmm3,xmm5
  25.          psllw     xmm3,8
  26.          por            xmm4,xmm3
  27.          pxor       xmm3,xmm3
  28.          punpckhbw        xmm0,xmm3
  29.          punpckhbw        xmm5,xmm3
  30.          psllw     xmm5,8
  31.          por            xmm5,xmm0
  32.          ;converting 16 + 16 digits into chars
  33.          movdqa   xmm1,[Bytes09]
  34.          movdqa   xmm2,[Bytes07]
  35.          pxor       xmm3,xmm3
  36.          movdqa   xmm0,xmm4
  37.          pcmpgtb          xmm0,xmm1
  38.          pblendvb         xmm3,xmm4,xmm0
  39.          paddb     xmm3,xmm2
  40.          pblendvb         xmm4,xmm3,xmm0
  41.          pxor       xmm3,xmm3
  42.          movdqa   xmm0,xmm5
  43.          pcmpgtb          xmm0,xmm1
  44.          pblendvb         xmm3,xmm5,xmm0
  45.          paddb     xmm3,xmm2
  46.          pblendvb         xmm5,xmm3,xmm0
  47.          movdqa   xmm1,[Bytes30]
  48.          paddb     xmm4,xmm1
  49.          paddb     xmm5,xmm1
  50.          ;unpacking
  51.          pmovzxbw         xmm0,xmm4                
  52.          psrldq   xmm4,8                   
  53.          pmovzxbw         xmm1,xmm4                
  54.          pmovzxbw         xmm2,xmm5                
  55.          psrldq   xmm5,8                   
  56.          pmovzxbw         xmm3,xmm5                
  57.          movdqu   [rdx+0x00],xmm0
  58.          movdqu   [rdx+0x10],xmm1
  59.          movdqu   [rdx+0x20],xmm2
  60.          movdqu   [rdx+0x30],xmm3
  61.          ret
  62.  
  63. export SSE42_16BytesToHex;

Батник:
Code:
  1. "C:\Progra~2\Nasm\nasm.exe" -f win64 YOURFILENAME.asm
  2. pause
По замерам (буффер предопределен и закеширован) - 25 тактов. Но это неважно, в IntToHex-е динамические строки и в purepascal-версии дополнительный динамический массив используется в конвертации. Вот из-за этого всё и тормозит.




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 10 июля 2018 20:31 · Поправил: difexacaw
· Личное сообщение · #21

bizkitlimp

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

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

-----
vx




Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 10 июля 2018 20:34
· Личное сообщение · #22

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

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 10 июля 2018 20:45 · Поправил: difexacaw
· Личное сообщение · #23

shellstorm

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

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

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

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

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

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

-----
vx




Ранг: 15.8 (новичок), 3thx
Активность: 0.030.01
Статус: Участник

Создано: 10 июля 2018 20:48
· Личное сообщение · #24

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

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

Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 10 июля 2018 21:01
· Личное сообщение · #25

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

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

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

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 10 июля 2018 21:05
· Личное сообщение · #26

shellstorm

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

-----
vx




Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 10 июля 2018 21:09 · Поправил: shellstorm
· Личное сообщение · #27

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

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 10 июля 2018 21:19
· Личное сообщение · #28

shellstorm

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

-----
vx




Ранг: -0.7 (гость), 170thx
Активность: 0.540
Статус: Участник

Создано: 10 июля 2018 21:23
· Личное сообщение · #29

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

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




Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 10 июля 2018 22:10
· Личное сообщение · #30

shellstorm

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

-----
vx





Ранг: 216.9 (наставник), 85thx
Активность: 0.310.15
Статус: Участник
X-Literator

Создано: 10 июля 2018 22:18
· Личное сообщение · #31

shellstorm пишет:
на момент создания и windows хейтили за слоупочность

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

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


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

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



<< . 1 . 2 . 3 . 4 . 5 . >>
 [email protected] —› Программирование —› ByteToHex
:: Ваш ответ
Жирный  Курсив  Подчеркнутый  Перечеркнутый  {mpf5}  Код  Вставить ссылку 
:s1: :s2: :s3: :s4: :s5: :s6: :s7: :s8: :s9: :s10: :s11: :s12: :s13: :s14: :s15: :s16:


Максимальный размер аттача: 500KB.
Ваш логин: german1505 » Выход » ЛС
   Для печати Для печати