Здравствуйте, minorlogic, Вы писали:

M>Ксатии про оптимизацию
M>http://www.minorlogic.com/projects/smartblend/index.htm
M>Меня все время спрашивают почему она так быстро работает ? Видимо я переписал все на SSE2 и т.д. А мне вроде как и неудобно рассказвать , что для доступа к пикселям изображения у меня используется ВИРТУАЛЬНАЯ функция.

А чего такого? Один-два виртуальных вызова на пиксел в ряде задач — это совершенно не страшно. Вот если их получается сотни на каждый пиксел — тогда проблемы. Хотя у меня были ситуации, когда и обычный вызов тормозил. Пришлось явно тыкать носом в виде __forceinline. Все это настолько эфемерно — зависит от тысяч факторов. Грамотная стратегия — это добиваться более-менее приемлемой производительности в среднем — для нескольких процессоров и нескольких компиляторов. И безо всяких ифдефов. И конечно же, только там, где это реально важно. К счастью, большинство моих задач именно такого свойства, другие мне не очень интересны

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>В одном не могу согласиться — очень уж мне не понравился последний пример. Он немного не о том.
SM>Более того, код, вероятно, изначально нужно было писать именно под 16-битную систему, без прямого указания на ориентацию на повышение разрядности. Невозможно предугадать решительно все направления, в которых могут развиваться системы, на которые предполагается в будущем ставить данный продукт...

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

Автор(ы): Стив Макконнелл

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

:

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

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

MS>>По всей видимости у вас именно такой случай...

M>Типа комплимент в мой адрес ? да ? вроде как это у меня случайно получилось ? Нечаянно ? Ну пасиб , уважил ...

Я привел возможный ответ на вопрос почему твой код быстрее, чем код с использованием встраеваемых template.
Не знаю могут ли современные компиляторы генерить код с использованием SSE2.
Если могут, то такое объяснение очень даже вероятно.

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, VladD2, Вы писали:

MS>>> То же самое — со встроенным профайлером в VC6.

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

MS>VC6 мне нравится ураганной скоростью компиляции при приемлемом качестве оптимизации. Я и во времена 386-486 продолжал использовать Turbo-C 2.0 именно по этой причине. Вот такой я ретроград.

Ураганная скорость??? Э-э-э. Что-то я не заметил. В крайнем случае, быстрая. То же раньше приходилось на VC6 писать.

Это первое. Второе — это то, что отказ от поддержки VC6 для меня означает потерю чуть ли не половины моих потенциальных заказчиков. И этот аргумент перевешивает любые распальцовки с 8-ми бетами.


Это каким это образом ты заказчиков потеряешь?

---

VD>>Любое измерение вносит погрешнось. Даже сэмплинг. Но радует только то, что погрешность эта однородна. Так что уловить тенденцию и найти действительно тормозные куски все же можно. А там уже нужно прилагать свой опыт и чутье.

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


Что-же делать? Плюнуть на профилировку вообще? Ну, если чутьё сильное...

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Здравствуйте, minorlogic, Вы писали:

M>>Еще как можно ругать если он выделил 4 байта под айпишник в серьезной системе и НЕ НАПИСАЛ КОД обрабатывающий ошибку при использовании IPV6, хотя для системы 10 летней давности такой айпишник был бы просто некоректным ! и сообщение об ошибке должно было на этапе парсинга появится.
SM>А ошибки не будет. Просто из того, что вернула система, он прочитает только 4 байта, и потом будет по ним пытаться достучаться. Никаких исключений, никаких утечек памяти, — конкретно код, получающий айпишник, отрабатывает гладко — просто возвращает после перехода на IPv6 неверный результат. Ошибка возникает позже. Как и в приведенном автором статьи примере.

SM>Slicer

А вот если была возможность проверить скока байт система вернула ?

Здравствуйте, MShura, Вы писали:

MS>Я привел возможный ответ на вопрос почему твой код быстрее, чем код с использованием встраеваемых template.
MS>Не знаю могут ли современные компиляторы генерить код с использованием SSE2.
MS>Если могут, то такое объяснение очень даже вероятно.

Я бы отбросил эту версию как версия вероятность которой стремится к нуню

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, minorlogic, Вы писали:

M>>Ксатии про оптимизацию
M>>http://www.minorlogic.com/projects/smartblend/index.htm
M>>Меня все время спрашивают почему она так быстро работает ? Видимо я переписал все на SSE2 и т.д. А мне вроде как и неудобно рассказвать , что для доступа к пикселям изображения у меня используется ВИРТУАЛЬНАЯ функция.

MS>А чего такого? Один-два виртуальных вызова на пиксел в ряде задач — это совершенно не страшно. Вот если их получается сотни на каждый пиксел — тогда проблемы. Хотя у меня были ситуации, когда и обычный вызов тормозил. Пришлось явно тыкать носом в виде __forceinline. Все это настолько эфемерно — зависит от тысяч факторов. Грамотная стратегия — это добиваться более-менее приемлемой производительности в среднем — для нескольких процессоров и нескольких компиляторов. И безо всяких ифдефов. И конечно же, только там, где это реально важно. К счастью, большинство моих задач именно такого свойства, другие мне не очень интересны

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

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

Счас правда я пользуюсь фиксированными форматами RGBA32 , и RGBA во float плюс то же но с любым количеством каналов.
Потдерживать все возможные форматы , мне просто незачем.

Здравствуйте, McSeem2, Вы писали:

MS>VC6 мне нравится ураганной скоростью компиляции при приемлемом качестве оптимизации. Я и во времена 386-486 продолжал использовать Turbo-C 2.0 именно по этой причине.

Я тоже ретроград видимо. Одна из причин того что я пересел на Шарп была довольно быстрая скорость компиляции. Чуть быстрее 6-ки. Раз в 300-400 .

MS>Вот такой я ретроград. Это первое. Второе — это то, что отказ от поддержки VC6 для меня означает потерю чуть ли не половины моих потенциальных заказчиков. И этот аргумент перевешивает любые распальцовки с 8-ми бетами.

- Почему ваша батарея не вела огонь?!
— На то есть несколько причин. Первая — небыло снарядов...

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

Сдается мне, что все же дело в средстве.

Здравствуйте, _Dimka_, Вы писали:

_D_>Ну-ну. Если в VC 7.0 включить режим Detect 64-bit portability, то половину программистов на планете надо будет просто перестрелять за то, что они не думали о будущих платформах

Ну, хорошо хоть половину.

Здравствуйте, VladD2, Вы писали:

MS>>VC6 мне нравится ураганной скоростью компиляции при приемлемом качестве оптимизации. Я и во времена 386-486 продолжал использовать Turbo-C 2.0 именно по этой причине.

VD>Я тоже ретроград видимо. Одна из причин того что я пересел на Шарп была довольно быстрая скорость компиляции. Чуть быстрее 6-ки. Раз в 300-400 .

О! Были времена... Во времена Turbo-C 1.5 MS выпустила некий Quick-C, который, якобы быстрее. Формально, компилятор из командной строки действительно показывал некоторое незначительное преимущество. Но при этом из IDE, от нажатия кнопки до запуска скомпилированного бинарника проходило раза в 3 больше времени, чем в Turbo-C. Чисто за счет огромного количества файловых операций.
Теперь — аналогичная фигня. За то время, пока стартует framework, VC6 успевает собрать 2-3 моих демо-примера.
Сам лично замерял.

VD>Сдается мне, что все же дело в средстве.

Именно! Первое, что надо сделать после установки VS 2003 это отключить нафиг эту глюкалу под названием "Intellisense":


После этого как правило происходит GPF.
Или VS 2003 тоже место на свалке? Но если так, то они уже просто достали своими релизами!

Здравствуйте, MShura, Вы писали:

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

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

Здравствуйте, McSeem2, Вы писали:

MS>Грамотная стратегия — это добиваться более-менее приемлемой производительности в среднем — для нескольких процессоров и нескольких компиляторов. И безо всяких ифдефов. И конечно же, только там, где это реально важно.

К сожалению, не всегда получается. Приходится в первую очередь оптимизировать программу именно для самого слабого процессора (слабой платформы). И если процессор очень долго выполняет ветвление по call или jump, уже десять раз начинаешь задумываться о лишней функции (особенно виртуальной).

ЗЫ Для меня одним из самых действенных методом оптимизации программы оказалось в свое время отключение exception handling. Все-таки очень много всего генерится на enter/leave в каждой функции..

Здравствуйте, _Dimka_, Вы писали:

_D_>Здравствуйте, McSeem2, Вы писали:

MS>>Грамотная стратегия — это добиваться более-менее приемлемой производительности в среднем — для нескольких процессоров и нескольких компиляторов. И безо всяких ифдефов. И конечно же, только там, где это реально важно.

_D_>К сожалению, не всегда получается. Приходится в первую очередь оптимизировать программу именно для самого слабого процессора (слабой платформы). И если процессор очень долго выполняет ветвление по call или jump, уже десять раз начинаешь задумываться о лишней функции (особенно виртуальной).

_D_>ЗЫ Для меня одним из самых действенных методом оптимизации программы оказалось в свое время отключение exception handling. Все-таки очень много всего генерится на enter/leave в каждой функции..

Что ж у тебя за архитектура такая, а?! Я за счёт таких вещей никогда ничего выиграть не мог.

Здравствуйте, FDSC, Вы писали:

FDS>Что ж у тебя за архитектура такая, а?! Я за счёт таких вещей никогда ничего выиграть не мог.
Архитектура, конечно, извращенная (Процессор Моторольный, эквивалент 200 MHz Intel), но если функции достаточно компактные, потери могут быть существенные. Простой пример: функция

void func(void)
{
    ClassSample  a;
    func2();
    return;
}

Дает код при запрете exception handling (в Release версии):

00403740  sub         esp,194h 
00403746  lea         ecx,[esp] 
00403749  call        ClassSample::ClassSample (4010B0h) 
0040374E  call        func2 (4010C0h) 
00403753  lea         ecx,[esp] 
00403756  call        ClassSample::~ClassSample (4010C0h) 
0040375B  add         esp,194h 
00403761  ret

И при наличии exception handling:

00403AD0  push        0FFFFFFFFh 
00403AD2  push        offset __ehhandler$?func@@YAXXZ (40FFCBh) 
00403AD7  mov         eax,dword ptr fs:[00000000h] 
00403ADD  push        eax  
00403ADE  mov         dword ptr fs:[0],esp 
00403AE5  sub         esp,194h 
00403AEB  lea         ecx,[esp] 
00403AEE  call        ClassSample::ClassSample (4010C0h) 
00403AF3  mov         dword ptr [esp+19Ch],0 
00403AFE  call        func2 (4010D0h) 
00403B03  lea         ecx,[esp] 
00403B06  mov         dword ptr [esp+19Ch],0FFFFFFFFh 
00403B11  call        func2 (4010D0h) 
00403B16  mov         ecx,dword ptr [esp+194h] 
00403B1D  mov         dword ptr fs:[0],ecx 
00403B24  add         esp,1A0h 
00403B2A  ret

Здравствуйте, minorlogic, Вы писали:

M>А вот если была возможность проверить скока байт система вернула ?
А зачем? Может, размер структуры, на которую нам дают указатель, изменился в новой версии системы — а новые, лишние поля меня просто не интересуют

Slicer

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>А зачем? Может, размер структуры, на которую нам дают указатель, изменился в новой версии системы — а новые, лишние поля меня просто не интересуют

Ну дык и получите либо неинициализированные поля, либо прога будет отказываться добавлять в список новые IP, отличающиеся в пятом байте, мотивируя это тем, что "IP address already exist" . Тут, как ни крути, нужно было прикручивать поле dwSize или что-то еще подобное.

Здравствуйте, _Dimka_, Вы писали:

_D_>Здравствуйте, McSeem2, Вы писали:

MS>>Грамотная стратегия — это добиваться более-менее приемлемой производительности в среднем — для нескольких процессоров и нескольких компиляторов. И безо всяких ифдефов. И конечно же, только там, где это реально важно.

_D_>К сожалению, не всегда получается. Приходится в первую очередь оптимизировать программу именно для самого слабого процессора (слабой платформы). И если процессор очень долго выполняет ветвление по call или jump, уже десять раз начинаешь задумываться о лишней функции (особенно виртуальной).

_D_>ЗЫ Для меня одним из самых действенных методом оптимизации программы оказалось в свое время отключение exception handling. Все-таки очень много всего генерится на enter/leave в каждой функции..

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

Здравствуйте, McSeem2, Вы писали:

MS>О! Были времена... Во времена Turbo-C 1.5 MS выпустила некий Quick-C, который, якобы быстрее. Формально, компилятор из командной строки действительно показывал некоторое незначительное преимущество.

Гы. Расказ о слухах очевидцам. Я как бы пользовался Quick-C. Компилятор действительно летал как трофейны месер. Только вот из командной строки он не работал. Он работа из среды. А из командной строки запусклася МС С. Может и модифицированный, но все равно не тот.

MS> Но при этом из IDE, от нажатия кнопки до запуска скомпилированного бинарника проходило раза в 3 больше времени, чем в Turbo-C.

Сказочник. Я на ХТ-юхе работал и всегда запуск был молниеносным. Хотя конечно Turbo-C тоже был шустр.

Кстати, а какое это отношение к делу имеет?

MS> Чисто за счет огромного количества файловых операций.

Класс! Вот только небыло их. По тому Quick-C 1.0 и летал как мессер. Он все в памяти держал. От того были серьезные проблемы с размером проектов.

Вот Turbo-C 1.5 уже файлы читал. Но и тормозил по сравнению с 1.0 не по детски.

MS>Теперь — аналогичная фигня. За то время, пока стартует framework, VC6 успевает собрать 2-3 моих демо-примера.
MS>Сам лично замерял.

Что замерял то? Самому то не стыдно? Возми 3 мега искходников и скомпилируй их на своем любимом VC6. Затем на Шарпе. Увидишь, что VC6 уйдет в даун минут на 5-15, а шарп за пару секунд отстреляется.

VD>>Сдается мне, что все же дело в средстве.

MS>Именно! Первое, что надо сделать после установки VS 2003 это отключить нафиг эту глюкалу под названием "Intellisense":

Нда, я то вообще-то про профайлер речь вел.

Здравствуйте, _Dimka_, Вы писали:

_D_>Здравствуйте, FDSC, Вы писали:

FDS>>Что ж у тебя за архитектура такая, а?! Я за счёт таких вещей никогда ничего выиграть не мог.
_D_>Архитектура, конечно, извращенная (Процессор Моторольный, эквивалент 200 MHz Intel), но если функции достаточно компактные, потери могут быть существенные. Простой пример: функция
_D_>

_D_>void func(void)
_D_>{
_D_>    ClassSample  a;
_D_>    func2();
_D_>    return;
_D_>}
_D_>

_D_>Дает код при запрете exception handling (в Release версии):
_D_>

_D_>00403740  sub         esp,194h 
_D_>00403746  lea         ecx,[esp] 
_D_>00403749  call        ClassSample::ClassSample (4010B0h) 
_D_>0040374E  call        func2 (4010C0h) 
_D_>00403753  lea         ecx,[esp] 
_D_>00403756  call        ClassSample::~ClassSample (4010C0h) 
_D_>0040375B  add         esp,194h 
_D_>00403761  ret              
_D_>

_D_>И при наличии exception handling:
_D_>

_D_>00403AD0  push        0FFFFFFFFh 
_D_>00403AD2  push        offset __ehhandler$?func@@YAXXZ (40FFCBh) 
_D_>00403AD7  mov         eax,dword ptr fs:[00000000h] 
_D_>00403ADD  push        eax  
_D_>00403ADE  mov         dword ptr fs:[0],esp 
_D_>00403AE5  sub         esp,194h 
_D_>00403AEB  lea         ecx,[esp] 
_D_>00403AEE  call        ClassSample::ClassSample (4010C0h) 
_D_>00403AF3  mov         dword ptr [esp+19Ch],0 
_D_>00403AFE  call        func2 (4010D0h) 
_D_>00403B03  lea         ecx,[esp] 
_D_>00403B06  mov         dword ptr [esp+19Ch],0FFFFFFFFh 
_D_>00403B11  call        func2 (4010D0h) 
_D_>00403B16  mov         ecx,dword ptr [esp+194h] 
_D_>00403B1D  mov         dword ptr fs:[0],ecx 
_D_>00403B24  add         esp,1A0h 
_D_>00403B2A  ret              
_D_>

И что, очень часто такие функции вызываются? Ведь обычно доля таких довольно мала.

Хотя, конечно, сразу ясно, что тут работает гораздо быстрее.

Здравствуйте, VladD2, Вы писали:

VD>Гы. Расказ о слухах очевидцам. Я как бы пользовался Quick-C.

Да ладно тебе. Это была шуткаблин!

Про intellisense — правда, но это к теме не относится. Хотя, косвенно тоже относится — есть подозрение, что Intellisense, который действительно работает быстро, является типичной жертвой premature optimization, о которой идет речь в статье... VisualAssist работает граздо тормознее, но зато и не падает.