ВУЗ для IT специалиста: взгляд изнутри

← →
картман © (2013-05-16 16:25) [120]

> DevilDevil © (16.05.13 15:34) [101]

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

тут вроде речь не идет о ЯП, не так ли?

Данный бенчмарк выполняет запись 100мб текстового файла.
...
Так вот раньше этот метод был реализован на ЯВУ и реализация
> выполнялась больше секунды. Сейчас она частично переписана
> на ассемблер и выполняется 265 миллисекунд

а у меня даже SSD не пишет со скоростью 400Мб/сек, что за железо? Даже есть за 156мсек - 640 Мб/сек, шикарно. Есть уверенность, что измеряется скорость записи на диск?

← →
DevilDevil © (2013-05-16 16:31) [121]

Удалено модератором

← →
Ega23 © (2013-05-16 16:31) [122]

Удалено модератором

← →
DevilDevil © (2013-05-16 16:35) [123]

> картман © (16.05.13 16:25) [120]

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

По поводу диска... очевидно он пишет в файловый или дисковый кеш. Ибо диски с такой скоростью писаться не умеют. Но локальную задачу модификации внутреннего буфера очевидно он выполняет в несколько раз быстрее. Ты по прежнему уверен, что разница между ассемблером и ЯВУ (Delphi) невелика ? )))

← →
DevilDevil © (2013-05-16 16:36) [124]

> Ega23 © (16.05.13 16:31) [122]

> Прикольно. А при чём тут я?

это не ты мучил FTS1Intersect ?

← →
Romkin © (2013-05-16 16:37) [125]

> а у меня даже SSD не пишет со скоростью 400Мб/сек, что за
> железо? Даже есть за 156мсек - 640 Мб/сек, шикарно. Есть
> уверенность, что измеряется скорость записи на диск?

http://www.nix.ru/support/bench/goods_compare.html?test_id=192
диск дает скорость 100-200 Мб/сек. Поэтому оптимизацию следовало остановить по достижении данной скорости. Разумеется, то, что сделано, оптимизирует общение с кешем ОС, а посему бессмысленно.

← →
Ega23 © (2013-05-16 16:40) [126]

Удалено модератором

← →
DevilDevil © (2013-05-16 16:41) [127]

> Romkin © (16.05.13 16:37) [125]

что что сделано - оптимизирует наполнение внутреннего буфера
связь с кешем ОС здесь на уровне стандартных АПИ-функций
никакого хинта для-подсказки типа "не пиши на диск, пиши в память" тут нет

я не знаю какой процент времени тут идёт на обмен памятью между внутренним буфером и ОС
факт в том, что в данном случае разница между ЯВУ-реализацией и асм-реализацией по производительности в разы. Или этот факт ты тоже станешь отрицать ? )

← →
Inovet © (2013-05-16 16:45) [128]

> [126] Ega23 © (16.05.13 16:40)
> потому как люди чаще всего ищут нестрогое совпадение, причём
> ещё и case insensitive.
...
> А ещё есть такая хрень, как автоподстановка, которая при
> варианте хранения данных в хэш-таблице работать как бэ не будет...

Плохая программа, плохие пользователи, оптимизировать нечего.

← →
Ega23 © (2013-05-16 16:45) [129]

> это не ты мучил FTS1Intersect ?

У нас нет FTS1Intersect. А когда были недолгие эксперименты с ним, то, ЕМНИП, основная проблема была в реаллоках памяти при сборке сортированных данных.

← →
Romkin © (2013-05-16 16:46) [130]

> факт в том, что в данном случае разница между ЯВУ-реализацией
> и асм-реализацией по производительности в разы. Или этот
> факт ты тоже станешь отрицать ? )

Нет. В два-три раза (ну пять) следует ожидать прироста при переходе на ассемблер. Вот только чаще всего это не нужно. Слишком маленький прирост.

← →
картман © (2013-05-16 16:47) [131]

> DevilDevil © (16.05.13 16:35) [123]

> По поводу диска... очевидно он пишет в файловый или дисковый
> кеш. Ибо диски с такой скоростью писаться не умеют.

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

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

← →
DevilDevil © (2013-05-16 16:48) [132]

Удалено модератором

← →
Ega23 © (2013-05-16 16:50) [133]

Удалено модератором

← →
DevilDevil © (2013-05-16 16:53) [134]

> Romkin © (16.05.13 16:46) [130]

> Нет. В два-три раза (ну пять) следует ожидать прироста при
> переходе на ассемблер. Вот только чаще всего это не нужно.
> Слишком маленький прирост.

4 раза это маленький прирост ?
я не агитирую использование ассемблера повсюду
я указываю на явную возможность выжать больше производительсти

← →
DevilDevil © (2013-05-16 16:58) [135]

> картман © (16.05.13 16:47) [131]

> не понятно, в чем оптимизация, если твой код измеряет скорость
> записи не на диск - предполагалось же, что оптимизация коснется
> именно скорости записи на диск. Или я ошибаюсь?

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

самая ощутимая оптимизация в том, что используется внутренний буфер. (кстати посмотри разницу с TFileStream-реализацией)

а вот способ заполнения этого внутренного буфера оказался важным. Есть Fast-вариант. А есть Simple вариант, с явным вызовом функции Write(). Так вот если раньше там вызывался системный Move(), то сейчас частоиспользуемая часть функции - на ассемблере. Поэтому и производительность скакнула

← →
Ega23 © (2013-05-16 16:59) [136]

> 4 раза это маленький прирост ?

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

В 99.9999% это нафиг не нужно никому.

← →
DevilDevil © (2013-05-16 17:00) [137]

Удалено модератором

← →
Ega23 © (2013-05-16 17:01) [138]

> что увеличу производительность на 50%

Производительность чего именно?

← →
DevilDevil © (2013-05-16 17:01) [139]

> Ega23 © (16.05.13 16:59) [136]

> В 99.9999% это нафиг не нужно никому.

это нужно там, где нужна производительность
там где код выполняет 1 или 5 милисекунд - производительность не нужна

← →
DevilDevil © (2013-05-16 17:02) [140]

> Ega23 © (16.05.13 17:01) [138]
>
> Производительность чего именно?

поисковой системы

← →
Kerk © (2013-05-16 17:03) [141]

Удалено модератором

← →
Romkin © (2013-05-16 17:03) [142]

> 4 раза это маленький прирост ?я не агитирую использование
> ассемблера повсюдуя указываю на явную возможность выжать
> больше производительсти

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

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

← →
DevilDevil © (2013-05-16 17:06) [143]

Удалено модератором

← →
картман © (2013-05-16 17:06) [144]

> DevilDevil © (16.05.13 16:58) [135]

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

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

← →
Romkin © (2013-05-16 17:07) [145]

> зри в кореньв данном случае оптимизация в 4 раза была не
> за счёт взаимодействия с диском ОСа за счёт того, что стандартные
> ЯВУ-средства были заменены ассемблеромферштейн ?

Тест на запись 10Гб провел?

← →
Ega23 © (2013-05-16 17:08) [146]

> поисковой системы

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

← →
картман © (2013-05-16 17:08) [147]

> а за счёт того, что стандартные ЯВУ-средства были заменены
> ассемблером

ты ошибаешься

← →
DevilDevil © (2013-05-16 17:08) [148]

Удалено модератором

Лучше все-таки в тему ветки. Иначе судьба ваши прений предсказуема - закрытие и баны активных участников

Удалено модератором

Поддерживаю модель
- Техникум выпускает кодеров
- Вуз - для повышения квалификации.

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

> картман © (16.05.13 17:14) [153]

> Дабы сократить количество пинаний очевидного туда-сюда -
> что там с записью 10Гб?

ЯВУ будет по прежнему медленнее ассемблера
Селяви

> Romkin (16.05.2013 16:46:10) [130]

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

> картман © (16.05.13 17:14) [153]

а вообще исходники открыты
http://sourceforge.net/projects/cachedbuffers/

замути тест на 100Гб с ассемблерной реализацией и с ЯВУ-реализацией
(смотри метод Write(), дифайн PURE_PASCAL)

> DevilDevil © (16.05.13 17:16) [155]
>
> > картман © (16.05.13 17:14) [153]
>
> > Дабы сократить количество пинаний очевидного туда-сюда
> -
> > что там с записью 10Гб?
>
> ЯВУ будет по прежнему медленнее ассемблера

Будет. На сколько?

> Romkin (16.05.2013 17:03:22) [142]

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

> DevilDevil © (16.05.13 17:20) [157]
>
> > картман © (16.05.13 17:14) [153]
>
> а вообще исходники открыты

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

ВУЗ для IT специалиста: взгляд изнутри Найти похожие ветки