Самый быстрый способ считать маленький файл в строку

← →
Rouse_ © (2011-10-14 21:11) [40]

> Anatoly Podgoretsky © (14.10.11 21:06) [38]
> Это пример не профессионализма. Тупо сделаный код.

Собственно именно эту мысль я и попытался озвучить в первом посте :)

← →
Rouse_ © (2011-10-14 21:19) [41]

> Игорь Шевченко © (14.10.11 20:56) [36]
> Во-вторых, открываем внутренности VCL и видим примеры нормального
> ассемблера.

Начиная с 2007-ой дельфи асм реализаця части функций очень сильно похорошела за счет использования наработок сторонних разрабочиков, часть пошла от Fast Code часть от Пиета, поэтому я и спросил по поводу "старых дельфийских библиотек"

← →
Игорь Шевченко © (2011-10-14 21:20) [42]

Rouse_ © (14.10.11 20:57) [37]

1. наборы SSE и VMX тебя приятно поразят разнообразием применения префиксов группы REP.

2. В Intel сидят далеко не дураки, и в новых архитектурах они оптимизируют выполнение старого набора инструкций.

"Intel microarchitecture (Nehalem) improves the performance of REP strings significantly
over previous microarchitectures in several ways:
• Startup overhead have been reduced in most cases relative to previous microarchitecture,
• Data transfer throughput are improved over previous generation
• In order for REP string to operate in “fast string“ mode, previous microarchitectures
requires address alignment. In Intel microarchitecture (Nehalem), REP
string can operate in “fast string” mode even if address is not aligned to 16 bytes"

(Intel® 64 and IA-32
Architectures
Optimization Reference Manual
Order Number: 248966-020
November 2009)
http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html

там оно правда про MOVSx

← →
Rouse_ © (2011-10-14 21:24) [43]

> Игорь Шевченко © (14.10.11 21:20) [42]

Согласен, CLMUL инструкции плана PCLMULLQLQDQ/PCLMULQDQ туда-же, но я не об этом, а о том что код не оптимизирован :)

← →
Игорь Шевченко © (2011-10-14 21:29) [44]

Rouse_ © (14.10.11 21:19) [41]

> Начиная с 2007-ой дельфи асм реализаця части функций очень
> сильно похорошела

в RTL от XE2 все те же REPNE SCASB

← →
Игорь Шевченко © (2011-10-14 21:30) [45]

Rouse_ © (14.10.11 21:24) [43]

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

← →
Rouse_ © (2011-10-14 21:38) [46]

> Игорь Шевченко © (14.10.11 21:30) [45]
> Там вообще черт голову сломит с этими префиксами, учитывая
> что префикс REX может быть вставлен в середину команды.

Хм, однако(думал ты забросил это дело отслеживать)...
Тогда, думаю будет интересно: http://www.beaengine.org/

← →
Anatoly Podgoretsky © (2011-10-14 21:44) [47]

> Rouse_ (14.10.2011 21:11:40) [40]

Они думаю, что если применют аггрегатную функцию, inc edi, inc esi, dec
ecx - то мол будет быстрееЮ будет но на 486 процессоре, а не на пентиум и
наследниках. Там лучше вместо одной функции сделать несколько. Так и
компилятор построен, вместо loop - пара dec ecx, jnz label. а со scasb и еще
быстрее.
В свое время когдя я еще этого не знал, то так и поступал, а потом
попробовал заменить одну команду несколькими и был удивлен, и только потом
посмотрел документацию Интела и другие умные книги, часть статей по
оптимизации ассемблера есть на моем сайте.

← →
Anatoly Podgoretsky © (2011-10-14 21:49) [48]

> Игорь Шевченко (14.10.2011 21:20:42) [42]

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

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

← →
Rouse_ © (2011-10-14 21:57) [49]

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

Есть у меня старая задачка, в свое время взламывал ей мозг Зотычу :)
Задача на знание оптимизации компилятора.

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

← →
Игорь Шевченко © (2011-10-14 22:05) [50]

Anatoly Podgoretsky © (14.10.11 21:49) [48]

> Наверно оптимизируют, но не только их, а и обычные тоже.

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

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

Ассемблер-то старый, а вот аппаратная платформа она интересная.

> В Пентиум IV они достигли выполнения обычных команд до 5
> за один так. В
> следующем поколение они потеряли это

Сейчас я не пойму, как померить относительно Пентиума.

"The front end can decode up to 4 instructions in one cycle and
supports two hardware threads by decoding the instruction streams between two
logical processors in alternate cycles. The front end includes enhancement in branch
handling, loop detection, MSROM throughput, etc. These are discussed in subsequent
sections.
The scheduler (or reservation station) can dispatch up to six micro-ops in one cycle
through six issue ports (five issue ports are shown in Figure 2-5; store operation
involves separate ports for store address and store data but is depicted as one in the
diagram).
The out-of-order engine has many execution units that are arranged in three execution
clusters shown in Figure 2-5. It can retire four micro-ops in one cycle, same as
its predecessor."

Если учесть, что одна микрооперация может представлять собой две команды уровня Instruction set architecture или одна команда может разбита на несколько микроопераций.

Rouse_ © (14.10.11 21:38) [46]

> Тогда, думаю будет интересно: http://www.beaengine.org/

Благодарю.

← →
Игорь Шевченко © (2011-10-14 22:12) [51]

Rouse_ © (14.10.11 21:57) [49]

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

первое, что приходит в голову - CBW/CWD
второе - INC EAX
третье - AAA/AAS/DAA/DAS

Что я упустил ? ;)

← →
Rouse_ © (2011-10-14 22:19) [52]

> Игорь Шевченко © (14.10.11 22:12) [51]
>
> Rouse_ © (14.10.11 21:57) [49]
>
>
> > Необходимо написать функцию, которая принимает на вход
> параметр
> > и выдает результат модификации оного, при этом занимает
> > всего один байт, если посчитать размер асм инструкций,
> из
> > которых она состоит.
>
>
> первое, что приходит в голову - CBW/CWD
> второе - INC EAX
> третье - AAA/AAS/DAA/DAS
>
> Что я упустил ? ;)

Минимум постфикс функции :)

← →
Rouse_ © (2011-10-14 22:20) [53]

> Rouse_ © (14.10.11 22:19) [52]
> Минимум постфикс функции :)

Но блин, это не честная подсказка :)

← →
Rouse_ © (2011-10-14 22:21) [54]

ЗЫ: Игорь - решение не публикуй плз, бо не интересно будет...

← →
Игорь Шевченко © (2011-10-14 22:28) [55]

> Минимум постфикс функции :)

Понял :)

← →
Anatoly Podgoretsky © (2011-10-15 01:18) [56]

> Игорь Шевченко (14.10.2011 22:05:50) [50]

Это что за железо страшное?

← →
Игорь Шевченко © (2011-10-15 10:38) [57]

> Это что за железо страшное?

corei7

злые Вы, чтож вы прикопались к этой REPNE SCASB
я же сам над собой посмеялся в своем посте...
ветка про чтение файла, а не про асм

а выпилено сие из Delphi7.SysUtils.StrLen с минимальными модификациями

All
сложность задачи не в ассемблере, а в дисковых операциях. Это очень медленно
если говорить хранение результата - то лучше писать в TMemoryStream например <Size><Память>. Там буферизация по 8кб - удастся избежать реаллоков

Nucer
существует возможность хранить все файлы одним zip архивом ?
если да то имеет смысл читать данные из архива

← →
Nucer (2011-10-20 23:55) [61]

Спасибо за ответы. Думал, что тема себя почти сразу исчерпала, поэтому сюда не заглядывал.

Поставлю точку :)

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

Жаль, что так и не удалось послушать начальника транспортного цеха.

Ты тратишь время на "склейку" (чтение + запись) и на последующее чтение. В итоге в скорости ты проигрываешь.
Удачи.

← →
Nucer (2011-10-22 23:38) [63]

> Ты тратишь время на "склейку" (чтение + запись) и на последующее чтение.
> В итоге в скорости ты проигрываешь.

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

← →
БезымянныйСтудент (2011-11-02 11:06) [64]

Какая связь между "самый быстрый способ считать файл" и "необходимо обрабатывать около 50 тысяч файлов"?
У вас же все время уходит на поиск и и открытие файлов, а не на само чтение...
Храните всё в одном файле... Или в БД...

Самый быстрый способ считать маленький файл в строку Найти похожие ветки