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

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

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

-----
z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh

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

difexacaw пишет:
Вы реально знаете все эти наборы, что можите свободно их кодить o_0 ?
Для тех, кто пользуется отладчиком, в этом ничего сложного нет.

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

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

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

Crawler пишет: По-вашему, это связано с языком, а не с реализацией?

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

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

ты просто сказочный *, но отвечу в последний раз, надоело тратить время на необучаемого *.
посмотри на clang, это стандартный компилятор apple, который заменил gcc, после посмотри на другое их детище, swift, после посмотри выхлоп, когда насмотришься, в example добавь ошибки и посмотри на выхлоп сборки. тоже самое можешь проделать с rust. вот в c++ builder выхлоп будет хуже, там из-за специфики компонентной модели и совместимости, часть оптимизаций отключили. с\с++ отвратительно парсятся и еще хуже раскрутить логику на уровне компиляции, а с этим возникают проблемы со статическим анализатором кода. это не язык такой классный, это историческое наследие в виде миллиардов строк кода и того, что когда то язык начали продвигать мейнстримные на тот день компании, с точки зрения дизайна они отвратительны, D существенно лаконичней и логичней, но он никогда не взлетит, переписывать код никто не будет, это дорого, а постепенный переход бессмысленный, язык недалеко ушел от плюсов, лучше разу брать проблемно-ориентированный язык или что-то уровнем выше сишки с ди.

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

Я лет 30 назад написал подпрограмму на основе просмотра BIOS IBM машины. По размеру она оптимальна, скорость можете проверить сами:
Byte2Hex proc
push ax
shr al,4
call Nible2Hex
pop ax
and al,0Fh
Nible2Hex proc
add al,90h
daa
adc al,40h
daa
stosb
ret
Nible2Hex endp
Byte2Hex endp

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

Да, симпатично.

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

MikDay пишет:
push ax
pop ax
если гнаться за размером, на eax надо бы махнуть, два префикса ж лишних получаются

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

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

dosprog пишет:
Это BIOS 30-летней давности машины
Я о практическом, а не гипотетическом применении.

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

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

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

Приведенная подпрограмма была написана в DOS эпоху. Сегодня, Вы правы, EAX, будет лучше. Но под Windows есть готовая wsprintf. Применение "самодельного" кода оправданно только в случаях, когда "сильно жмет" - иногда бывает для встроенных приложений в системах управления.
Кстати, приведенный код легко расширяется до Word2Hex/DWord2Hex.

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

MikDay пишет:
оправданно только в случаях, когда "сильно жмет"
Я это на протяжении 4 страниц пытаюсь доказать, но есть гурманы. Сам такое пользую только когда значения регистров общего назначения жалко, wsprintf их сожрет, а pushad некошерен.

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

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

f13nd пишет:
значения регистров общего назначения жалко, wsprintf их сожрет, а pushad некошерен.

) Там, где рассматривается возможность использования wsprintf(), - там pushad это пыль.



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

dosprog пишет:
) Там, где рассматривается возможность использования wsprintf(), - там pushad это пыль.
Это просто пунктик у меня такой. В прологе/эпилоге функции эти инструкции хороши, если в ней ebx/esi/edi используются, результат можно напрямую в стек воткнуть и popad его в eax поместит. А просто так их совать куда ни попадя некрасиво. Я уже устал доказывать, что программы тупят не потому, что не вылизаны идеально с точки зрения каких-то там оптимизаций.

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

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

f13nd

> wsprintf их сожрет, а pushad некошерен.

Ты что сдурел, функция вывода текста ядерная, очень толстая. Причём там какая то инструкция. Какой то бред.

-----
vx

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

difexacaw пишет:
ы что сдурел, функция вывода текста ядерная, очень толстая. Причём там какая то инструкция. Какой то бред.
Если бы я писал нотпад, которому было бы неплохо уметь перерабатывать текстовые файлы по несколько гигабайт, я бы вообще без апи все обрабатывал по-спортивному. Если задача вывести вшивую строчку в окне, вообще пофигу как это делать, хоть lua подключить и в нем строки форматировать, а потом забирать - ни на чем вообще не скажется.

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

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

экономия на спичках актуальна только для очень узкого круга задач, когда нужно втиснуться в рамки серьезных ограничений по размеру или памяти, в остальных случаях достаточно выхлопа качественного компилятора.
взять photoshop, неважно 1 в нем лишний регистр или 100500, в таком софте скорость определяется уже на уровне алгоритмов, насколько они быстрые и как правильно подобраны под задачу, если заниматься байтодрочеством, ничего кроме 100500 по счету notepad не напишите, а ms word со студией все таки удобней для своих задач, хоть их и можно делать в супер быстром блокноте.

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

shellstorm пишет:
экономия на спичках актуальна только для очень узкого круга задач
Даже скорее не так. Это ужасно, но ничьи программные шедевры ни в эрмитаже, ни в лувре никогда выставлять не будут, рядом с моно-лизой. Так что если нажатие одной кнопочки она будет обрабатывать на 1/1000 секунды быстрей, этого никто не оценит.

shellstorm пишет:
ms word со студией все таки удобней для своих задач, хоть их и можно делать в супер быстром блокноте.
Ты видимо гигабайтные парсы не разбирал, без уберблокнота байтодрочерского там никак Ворд вообще с блокнотами сравнивать некорректно, он про бумажные документы с картинками.

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

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

f13nd пишет: этого никто не оценит

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

f13nd пишет: Ты видимо гигабайтные парсы не разбирал, без уберблокнота байтодрочерского там никак

парсил xml на 10GB мне хватило обычного python'a, на хабре была статья, там парсился xml на 100GB, хватило powershell'a. в этой задаче байтодрочерство не особо нужно, здесь главное правильная работа с файлом, остальное вторично. это алгоритмическая задача, которая не решается за счет вылизывания кода. сколько не вылизывай код, а прямая загрузка файла в оперативную память поставит крест на всей оптимизации.
почему некорректно, кто-то запрещает делать форматирование вручную?

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

shellstorm пишет:
мне хватило обычного python'a
А можно было несколько кнопок нажать, без питона. Некорректно потому что этих кнопок в ворде нету, он тупо не предназначен для обработки данных, это текстовый фотошоп.

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

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

f13nd пишет: А можно было несколько кнопок нажать, без питона

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

f13nd пишет: Некорректно потому что этих кнопок в ворде нету

там их много, недавно запускал и точно больше чем в блокноте.

f13nd пишет: он тупо не предназначен для обработки данных

именно и предназначен для обработки текстовых данных, но не рассчитан на работу с большими данными, блокнот насколько я помню с таким же типом данных работает. тем более в word давно xml в архиве, xml можно править в блокноте который идет из коробки.

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

shellstorm пишет:
именно и предназначен для обработки текстовых данных, но не рассчитан на работу с большими данными
Ворд раскидает сплошняковый xml по тегу на строку, отметит нужные по регулярному выражению, потом другие по другому регулярному выражению и вытащит отмеченные в новый файл, а потом почистит дубли и отсортирует? Заменит по маске нужную конструкцию на ";", растащит по столбикам и даст нужный скопировать в другой файл?

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

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

f13nd пишет: растащит по столбикам и даст нужный скопировать в другой файл

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

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

shellstorm пишет:
а у блокнота нет даже подсветки xml
Я имел в виду блокнотЫ как класс, редакторы голого текста, они разительно отличаются от ворда.

shellstorm пишет:
IO HD является узким местом
Оперативки обычно много, если дать 64битному приложению ее побольше съесть, оно твои 10 гигов в два приёма переварит.

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

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

У меня обратный вопрос, какой быстрый код есть для перевода строки указателя (хекс) в int64 (под х64)?

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

VOLKOFF пишет:
для перевода строки указателя (хекс) в int64


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

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

VOLKOFF пишет:
У меня обратный вопрос, какой быстрый код есть для перевода строки указателя (хекс) в int64 (под х64)?


Адаптируй процедуру х32:



Usage:



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

dosprog пишет:
mul     ecx
А как же... скорость... прокрутки?..

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

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

Ну, оптимизируй.



Изначально аргументом MUL был RADIX.
В незапамятные 16-битные времена



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

Ммм... Вот рабочий вариант для понимания



Оптимизация и критика рукожопости приветствуется

Фига вы тут понаписали за минуту, пока я постил

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

VOLKOFF пишет:
cmp bl, $30            ; 0...9
jb  ._1
Меньше 30 там ничего быть не должно, можно сразу в .3 завернуть. Ну если аптимизировать, то еще
VOLKOFF пишет:
cmp bl, 0
на

VOLKOFF пишет:
mov rax, 0xFFFFFFFFFFFFFFFF
на


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

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

f13nd пишет:
Меньше 30 там ничего быть не должно
В идеальном мире да, ты был бы прав.

f13nd пишет:
test bl,bl
Целый процессорный такт!
Но - ок, нано-оптимизация нужна.

f13nd пишет:
xor rax,rax
dec rax
Вот это по делу.
От меня анонимный лайк

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

VOLKOFF пишет:
Целый процессорный такт!
Это минус один байт как бы
VOLKOFF пишет:
В идеальном мире да, ты был бы прав.
В неидеальном мире число меньше 30 по всем проверкам прокатится и туда же попадет. Но неоптимальным образом.

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

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

Пардоньте, с 'al' попутал, тогда бы они обе двухбайтовые были и разница в один такт.

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