Из описания одной утилитки на сайте производителя:

Вы можете использовать Tonecast как средство для организации передачи звука с CD-качеством с локального CD-ROM проигрывателя, FM-приёмника, MP3 проигрывателя, а также передачи неискаженных голосовых сообщений одновременно на все компьютеры сети. Алгоритмы сжатия MPEG в Vypress Tonecast реализованы на ассемблере и тщательно оптимизированы.

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

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

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

А пояснить? Или я пропустил переворот мира, из-за которого ассемблерные вставки перестали давать самый оптимальный код? Если, конечно, они правильно написаны и грамотно оптимизированы.

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

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

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

К>А пояснить? Или я пропустил переворот мира,
Думаю, что да.

К> из-за которого ассемблерные вставки перестали давать самый оптимальный код? Если, конечно, они правильно написаны и грамотно оптимизированы.
Да я вобщем-то с этим никогда и не спорил
У меня просто другие критерии софта, который мы называем "качественным".

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

V>У меня просто другие критерии софта, который мы называем "качественным".

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

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

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

Пишу на java и .net, но вот тебе минус. Чем ассемблер плох-то? Тем более это алгоритмы сжатия — их, имхо, и надо писать на асме, на крайняк — на си.
Интересно, вы решили, что на асме нельзя написать качественную программу потому, что сами не можете этого сделать? Ну не стоит всех в свою рамку вписывать.

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

E__>Интересно, вы решили, что на асме нельзя написать качественную программу
Неа. Я просто зашел на форум "коллеги улыбнитесь" и запостил то, что меня улыбнуло и всегда радовало: гордость за тщательно оптимизированные ассемберные вставки.

E__>потому, что сами не можете этого сделать?
Да, не могу. И никогда не хотел научиться.
А вот некоторые мои "более сознательные" коллеги могут. И до сих пор отлавливают ошибки в своих тщательно оптимизированных ассемблерных вставках.

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

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

V>А вот некоторые мои "более сознательные" коллеги могут. И до сих пор отлавливают ошибки в своих тщательно оптимизированных ассемблерных вставках.

Бесконечно отлавливать ошибки можно и в дотнетовских приложениях, и в джавовских, и в каких угодно. А вот заставить те же самые дотнет и джаву работать так же быстро и кушать так же мало памяти, как оптимизированные программы с применением ассемблера — задача, увы, недостижимая. Лично меня как пользователя, а не как программиста всегда дико раздражали программы, которые непонятно на что тратят кучу времени. Например, так всеми любимый MSI-инсталлятор: чем он вообще всё это время занимается?? Устанавливаю элементарнейшую прожку из пяти файлов общим размером около метра, вносятся две-три записи в реестр, и всё. На установку уходит секунд 20-30 (Athlon 64 3200+). А устанавливаю IrfanView (примерно такой же набор файлов по объёму) — от нажатия кнопки "Далее" на последнем шаге до появления окошка с надписью, что установка завершена, проходит меньше секунды! В прошлых версиях Ирфана, менее навороченных, это происходило вообще мгновенно.

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

Константин wrote:
> Например, так всеми любимый MSI-инсталлятор: чем он вообще всё это
> время занимается??
Например тем, что создает информацию для отката в случае ошибки.

Если во время установки Infran'а случится ошибка, то на диске останется
недоустановленный Infran. Если во время установки MSI произойдет ошибка,
то установка будут откачена обратно (включая ключи реестра,
зарегистрированные typelib'ы, замененные системные файлы и т.п.).

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

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

E__>>Интересно, вы решили, что на асме нельзя написать качественную программу
V>Неа. Я просто зашел на форум "коллеги улыбнитесь" и запостил то, что меня улыбнуло и всегда радовало: гордость за тщательно оптимизированные ассемберные вставки.

А почему нет? Я сам на асме давненько ничего не делал(вообще последний раз в еще школе чего-то писал, ну и лабы в инсте да пару раз переходы ставил на несколько байт, дабы не мучала прога сообщением о регистрации — ессно спец по асму из меня нулевой). Однако когда я вижу реально быстро работающий код (в принципе, не обязательно на асме, но на нем можно написать САМЫЙ быстрый код из возможных) — я отношусь с уважением к тому, кто его писал. А то за.. надоело вобщем. Про винИнсталлер тут уже написали, еще туде же — клиентские тулзы для 2005 sql сервера. Чего они постоянно делают — непонятно, окошко открытия дерева выбора папок 2-3 секунды появляется...


E__>>потому, что сами не можете этого сделать?
V>Да, не могу. И никогда не хотел научиться.
V>А вот некоторые мои "более сознательные" коллеги могут. И до сих пор отлавливают ошибки в своих тщательно оптимизированных ассемблерных вставках.

Значит, не очень-то и могут. Получается так.

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

Хм.. А что есть "настоящий программист?"

А вообще, имхо, злоупотреблять асмом действительно не стоит. Но иногда он нужен — все как всегда: сначала ставим задачу, а потом выбираем, как ее реализовать. И для некоторых задач асм действительно лучшее решение (а для некоторых и вообще единственное). Имхо, писать алгоритмы сжатия на асме — вполне нормальное решение. Вот если бы на асме был интерфейс(GUI) — стоило бы задуматься.

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

C>Константин wrote:
>> Например, так всеми любимый MSI-инсталлятор: чем он вообще всё это
>> время занимается??
C>Например тем, что создает информацию для отката в случае ошибки.

C>Если во время установки Infran'а случится ошибка, то на диске останется
C>недоустановленный Infran. Если во время установки MSI произойдет ошибка,
C>то установка будут откачена обратно (включая ключи реестра,
C>зарегистрированные typelib'ы, замененные системные файлы и т.п.).

Хорошо, пусть создаёт. Элементарнейший подсчёт: забэкапить всё то, что будет заменено, это (считаю по максимуму):
1. Прочитать содержимое инсталлера, сравнивая, какие файлы и ключи реестра будут заменены.
2. Сделать куда-нибудь копию этих заменяемых.
3. Установить.
Т.о., в три раза больше времени. 3 секунды по Ирфану. Ну хорошо, накинем ещё вдвое на не знаю что. 6 секунд. MSI — 30 секунд. За 30 секунд можно гигабайт скопировать, а он этим явно не занимается. Есть ещё версии?

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

C>Константин wrote:
>> Например, так всеми любимый MSI-инсталлятор: чем он вообще всё это
>> время занимается??
C>Например тем, что создает информацию для отката в случае ошибки.

Блин, ни разу не видел НИ ОДНОГО инсталлятора с работающим откатом кроме 2005 студии.
Взять тот же вроде серьезный родной продукт — MSDE 2000. Нажмите "отмена" в процессе установки. И либо проведете остаток дня, пытаясь установить его заново, либо вообще потеряете возможность его установить на эту систему.

C>Если во время установки Infran'а случится ошибка, то на диске останется
C>недоустановленный Infran. Если во время установки MSI произойдет ошибка,
C>то установка будут откачена обратно (включая ключи реестра,
C>зарегистрированные typelib'ы, замененные системные файлы и т.п.).

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

О глюках отката: если происходит ошибка при откате(а это часто), то инсталлер в 99% случаев просто все проигнорировать и начать установку заново как ни в чем не бывало, не может. Это бесит больше тормозов.
А инсталлер без всяких откатов просто поставит поверх, и все.
Я как пользователь ненавижу мсинсталлер лютой ненавистью — он мне столько нервов перепортил

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

E__>Про винИнсталлер тут уже написали, еще туде же — клиентские тулзы для 2005 sql сервера. Чего они постоянно делают — непонятно, окошко открытия дерева выбора папок 2-3 секунды появляется...

Ну как что... ...JIT... дотнет даёт о себе знать

з.ы. Критичные по скорости участки можно писать и на asm'е , но не стоит этим увлекаться...

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

E__>>потому, что сами не можете этого сделать?
V>Да, не могу. И никогда не хотел научиться.
V>А вот некоторые мои "более сознательные" коллеги могут. И до сих пор отлавливают ошибки в своих тщательно оптимизированных ассемблерных вставках.
Нельзя уметь писать по-настоящему грамотный код на, скажем, C++, не зная и не представляя, в какой ассемблерный код это выльется при компиляции.
Поэтому, в критически важных по времени участках, использование собственного ассемблерного кода может дать наилучший результат — если суметь увидеть, что С++ код не будет в точности транслирован в нужную ассемблерную последовательность, и написать кусочек наилучшим образом.

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

V>Из описания одной утилитки на сайте производителя:
V>

V>Вы можете использовать Tonecast как средство для организации передачи звука с CD-качеством с локального CD-ROM проигрывателя, FM-приёмника, MP3 проигрывателя, а также передачи неискаженных голосовых сообщений одновременно на все компьютеры сети. Алгоритмы сжатия MPEG в Vypress Tonecast реализованы на ассемблере и тщательно оптимизированы.

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

Я пишу на Жабе корпоративные приложения. И уж точно не отношусь с пиететом к ассемблеру. Хочу сказать определенно — всякий шит тормозящий даже на двойных Зеонах с 3 гигами памяти ДОСТАЛ. Поэтому, если кто-то что-то оптимизировал на ассемблере, то это как минимум уважаемо как забота о нас.

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

V>Из описания одной утилитки на сайте производителя:
V>

V>Вы можете использовать Tonecast как средство для организации передачи звука с CD-качеством с локального CD-ROM проигрывателя, FM-приёмника, MP3 проигрывателя, а также передачи неискаженных голосовых сообщений одновременно на все компьютеры сети. Алгоритмы сжатия MPEG в Vypress Tonecast реализованы на ассемблере и тщательно оптимизированы.

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

Ну так сотрите свою любимую ОС И выкинте BIOS материнской платы

V>Щас ассемблерщики мне быстро минусов наставят

За что там минус-то? Двойные стандарты — это так смешно!

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

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

Загляните в исходники mplayer'а — там ассемблером не брезгуют. Зато на моем стареньком K6-2 266 МГц можно было смотреть MPEG4.

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

V>Я бы неспешил покупить программу, в которой часть, пусть даже и небольшая, написана на ассемблере, да еще и тщательно оптимизирована
На ассемблере скорее всего написано немного + возможность заюзать SSE1/2/3, что не всегда компиляторы (оптимально) делают.

А тормозящие программы действительно достали . Не хватает для простой программистской работы 768 Мб RAM!

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

ДД>Загляните в исходники mplayer'а — там ассемблером не брезгуют. Зато на моем стареньком K6-2 266 МГц можно было смотреть MPEG4.

Да, mplayer — это реально круто. С mpeg4 справляется даже P-166 MMX

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

К>Хорошо, пусть создаёт. Элементарнейший подсчёт: забэкапить всё то, что будет заменено, это (считаю по максимуму):
Он не только это бэкапит. Он создает точку восстановления. Это все-равно, что создать её вручную, столько-же времени займет.

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

J>Здравствуйте, Константин, Вы писали:

К>>Хорошо, пусть создаёт. Элементарнейший подсчёт: забэкапить всё то, что будет заменено, это (считаю по максимуму):
J>Он не только это бэкапит. Он создает точку восстановления. Это все-равно, что создать её вручную, столько-же времени займет.

Во-первых, что такое точка восстановления по сути? Чем она отличается от простого бэкапа специфического набора файлов и веток реестра? Лично я этого не знаю, но просто не могу себе представить, чего такого можно понапихать в точку восстановления, чтобы её создание занимало в 10 раз больше времени, чем тупое копирование.
Во-вторых, лично у меня служба восстановления отключена полностью, папки System Volume Information\ на всех дисках всегда пустые (за исключением двух служебных файлов). Что же в таком случе создаёт инсталлятор и куда он это складывает?
В-третьих, если так немеряно тормозит программа создания точек восстановления, это не значит, что MSI-инсталлятор нормальный, это значит, что они оба тормозные — и инсталлер, и программа. (Я надеюсь, под созданием точки вручную подразумевалось именно использование стандартной программы, а не ручное копирование нужных файлов? ).

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

D>Я пишу на Жабе корпоративные приложения. И уж точно не отношусь с пиететом к ассемблеру. Хочу сказать определенно — всякий шит тормозящий даже на двойных Зеонах с 3 гигами памяти ДОСТАЛ. Поэтому, если кто-то что-то оптимизировал на ассемблере, то это как минимум уважаемо как забота о нас.

BEA Weblogic?

На самом деле тормозит как правило не платформа или язык, а кривые ручки программистов, ленящихся почитать книжки про структуры данных и алгоритмы, и поэтому неумеющие их эффективно применять. Их не волнует, что допустим поиск элемента в выбранной структуре занимает O(n), находит, а это главное. Ну и про работу с потоками отдельная песня.

АХ>На ассемблере скорее всего написано немного + возможность заюзать SSE1/2/3, что не всегда компиляторы >Ю>(оптимально) делают.

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

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

J>Здравствуйте, Константин, Вы писали:

К>>Хорошо, пусть создаёт. Элементарнейший подсчёт: забэкапить всё то, что будет заменено, это (считаю по максимуму):
J>Он не только это бэкапит. Он создает точку восстановления. Это все-равно, что создать её вручную, столько-же времени займет.

А можно эту порчу отключать при установке?

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

E__>А можно эту порчу отключать при установке?

Свойства системы — ВОССТАНОВЛЕНИЕ Системы — Отключить восстановлении системы на всех дисках.

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

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

J>>Здравствуйте, Константин, Вы писали:

К>>>Хорошо, пусть создаёт. Элементарнейший подсчёт: забэкапить всё то, что будет заменено, это (считаю по максимуму):
J>>Он не только это бэкапит. Он создает точку восстановления. Это все-равно, что создать её вручную, столько-же времени займет.

К>Во-первых, что такое точка восстановления по сути? Чем она отличается от простого бэкапа специфического набора файлов и веток реестра? Лично я этого не знаю, но просто не могу себе представить, чего такого можно понапихать в точку восстановления, чтобы её создание занимало в 10 раз больше времени, чем тупое копирование.

Наверное Volume Shadow Copy задействовано.

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

_>Наверное Volume Shadow Copy задействовано.

Ето шо такое и где управляется?

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

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

_>>Наверное Volume Shadow Copy задействовано.

К>Ето шо такое и где управляется?

Я бы по-другому спросил: где это вырубить?

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

E__>Здравствуйте, Константин, Вы писали:

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

_>>>Наверное Volume Shadow Copy задействовано.

К>>Ето шо такое и где управляется?

E__>Я бы по-другому спросил: где это вырубить?

служба есть такая

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

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

_>>Наверное Volume Shadow Copy задействовано.

К>Ето шо такое и где управляется?

Служба такая. Для теневого копирования.

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

_>>>Наверное Volume Shadow Copy задействовано.

К>>Ето шо такое и где управляется?

_>Служба такая. Для теневого копирования.

Это-то я понял. Я не понял, что такое теневое копирование, нафига оно нужно, что, когда и куда она копирует "теневым образом" и чем это отличается от обычного копирования; как вся эта кухня настраивается и настраивается ли вообще (я не имею в виду просто запуск/остановку службы, с этим тоже всё ясно), ну и так далее. А просто перевести "Shadow Copy" с ангельского я уж как-нибудь и сам смог.

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

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

_>>>>Наверное Volume Shadow Copy задействовано.

К>>>Ето шо такое и где управляется?

_>>Служба такая. Для теневого копирования.

К>Это-то я понял. Я не понял, что такое теневое копирование, нафига оно нужно, что, когда и куда она копирует "теневым образом" и чем это отличается от обычного копирования; как вся эта кухня настраивается и настраивается ли вообще (я не имею в виду просто запуск/остановку службы, с этим тоже всё ясно), ну и так далее. А просто перевести "Shadow Copy" с ангельского я уж как-нибудь и сам смог.

Для конкретного процесса создаётся "снимок" тома, с которого он может копировать файлы и который не изменяется несмотря на то, что другие прцессы могут менять файлы на этом томе. Применяется для операций бэкапа. Его применение вполне может объяснить тормознутьсть MSI

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

XZ>Нельзя уметь писать по-настоящему грамотный код на, скажем, C++, не зная и не представляя, в какой ассемблерный код это выльется при компиляции.

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

Понимать, как ЯВУ отображается в ассемблер — это хорошо. Но ещё важнее понимать, почему он так отображается, и как этим процессом управлять.

XZ>Поэтому, в критически важных по времени участках, использование собственного ассемблерного кода может дать наилучший результат — если суметь увидеть, что С++ код не будет в точности транслирован в нужную ассемблерную последовательность, и написать кусочек наилучшим образом.

Да что вы все к этому убогому C++ прицепились? И ежу ясно, что оптимальный код из этого языка получить нельзя просто by design.

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

NB> Да что вы все к этому убогому C++ прицепились? И ежу ясно, что оптимальный код из этого языка получить нельзя просто by design.

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

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

skip

Сразу видно что человек даже не знаком с примитивным набором команд своего проца.
Если вы сможете найти хотябы один компилятор С/С++/С# который умеет генерить
распараллеленный код на MMX/SSE/SSE2/SSE3/3DNow! то все ассемблерщики сразу на него пересядут.
Почемуто наличие шэйдеров и инструкций GPU в трехмерных играх никого не смущает,
хотя это тот же ассемблер только для видеокарты.

Для примера расскажу как я выучил ассемблер.
Однажды на нашей фирме возникла необходимость обрабатывать
цветные изображения разрешения 768x576 с четырех видеокамер в реалтайме.
Каждая камера давала по 25 кадров в сек.
Первую версию алгоритма я написал на STL при помощи мегамодных итераторов и функторов.
После сборки в релизе проц справлялся только с 4-мя кадрами в сек. А нужно 100! Что делать?
Я потратил 2 недели на изучение SSE2 и еще неделю на реализацию.
5 десятков вылизанных инструкций свободно молотили 100 кадров, более того проц был загружен на 10%.
В SSE2 есть инструкция psadbw которая за такт считает сумму модулей разностей 16 байтов,
как раз то что там было нужно!

И еще, не существует ни одного нормального кодера/декодера видео, который не написан на асме,
я не имею в виду тот примитив типа mov, xchg и т.п. а современные расширения процессоров

unreg_flex wrote:
> Если вы сможете найти хотябы один компилятор С/С++/С# который умеет генерить
> распараллеленный код на MMX/SSE/SSE2/SSE3/3DNow! то все ассемблерщики
> сразу на него пересядут.
Intel C++ — уже много лет параллелит. Там при максимальном уровне
предупреждений даже выдается гордая надпись: "xx.cpp(yyy) : (col. nn)
remark: LOOP WAS VECTORIZED."

В GCC 4.1 тоже векторизация появилась, в 4.2 ее заметно расширят.

> Почемуто наличие шэйдеров и инструкций GPU в трехмерных играх никого не
> смущает, хотя это тот же ассемблер только для видеокарты.
Вот пример такого "ассемблера":

uniform sampler2D coeffsABC;
uniform sampler2D coeffsDEF;

void main( void )
{
   // Get the texture coordinates
   vec2 st = gl_TexCoord[0].st;

   // Read the polynomial coefficients from the textures
   vec3 ABC = vec3(texture2D(coeffsABC, st)-0.50196); // 8-bit signed,
   vec3 DEF = vec3(texture2D(coeffsDEF, st)-0.50196); // 128/255 -> 0.0

   // Construct vectors with powers of u and v
   vec3 uv1 = vec3(fract(st*32.0), 1.0);
   vec3 u2uvv2 = uv1.xxy * uv1.xyy;

   // Calculate the pixel size in (u,v) space for antialiasing
   vec4 duvdxy = 32.0*vec4(dFdx(st), dFdy(st));
   float stepwidth = 0.5*length(duvdxy);

   // Make a checkered pattern to show texel borders
   //vec2 cst = floor(mod(st*32.0, 2.0));
   //float c = mod(dot(cst, vec2(1.0, 1.0)), 2.0);

   // Evaluate the implicit curve polynomial
   float f = dot(ABC,u2uvv2) + dot(DEF,uv1);

   // Compute the magnitude of the gradient of the polynomial
   vec2 gradf = vec2(dot(uv1, vec3(2.0*ABC.x,ABC.y,DEF.x)),
     dot(uv1, vec3(2.0*ABC.z,ABC.y,DEF.y)));
   float g = inversesqrt(dot(gradf, gradf));

   // Set the color to be black when P<=0.0, white otherwise
   float a = smoothstep(-stepwidth, stepwidth, f*g);
   gl_FragColor = vec4(a, a, a, 1.0);
}

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

C>unreg_flex wrote:
>> Если вы сможете найти хотябы один компилятор С/С++/С# который умеет генерить
>> распараллеленный код на MMX/SSE/SSE2/SSE3/3DNow! то все ассемблерщики
>> сразу на него пересядут.
C>Intel C++ — уже много лет параллелит.

Вот только не там и не то. Я тоже обрабатывал изображения 768x576 с видеокамер
В принципе, VC тоже что-то такое делает, но в критических местах толку от этого ноль.

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

[skiped]
вы эту шутку напишите расскажите QNX разработчикам , они ее оценят

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

C>unreg_flex wrote:
>> Если вы сможете найти хотябы один компилятор С/С++/С# который умеет генерить
>> распараллеленный код на MMX/SSE/SSE2/SSE3/3DNow! то все ассемблерщики
>> сразу на него пересядут.
C>Intel C++ — уже много лет параллелит. Там при максимальном уровне
C>предупреждений даже выдается гордая надпись: "xx.cpp(yyy) : (col. nn)
C>remark: LOOP WAS VECTORIZED."

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

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

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

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

E__>Пишу на java и .net, но вот тебе минус. Чем ассемблер плох-то? Тем более это алгоритмы сжатия — их, имхо, и надо писать на асме, на крайняк — на си.
E__>Интересно, вы решили, что на асме нельзя написать качественную программу потому, что сами не можете этого сделать? Ну не стоит всех в свою рамку вписывать.


Почему нельзя? Конечно можно!

Просто мы живем в 21-ом веке, все со временем меняется, мировозрение и подход к разработке тоже меняется...

А) Раньше (80-ые — начало 90-ых) использовали ассемблер по двум причинам:

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

СЕГОДНЯ НЕ АКТУАЛЬНО: Компиляторы дошли до такого уровня, чтобы оптимизировать код не хуже человека, а в некоторых местах еще и лучше (человек может ошибиться и что-то пропустить, — компилятор — машина — не пропустит).

2. В те времена происходил бурный рост коммандного множества процессоров (раньше 8086 от 80286, 80486 от Pentium — разительно отличались не только рабочими частотами, а еще и объемами поддерживаемых комманд). Компиляторы не успевали за развитием процессоров. Следовательно, для реализации более быстрого кода с применением новых процессорных комманд необходимо было писать вставки на ассемблере — компилятор же все компилировал, грубо говоря, под 8086.

СЕГОДНЯ НЕ АКТУАЛЬНО: Сегодня все компиляторы поддерживают все современные комманды процессоров. А с выходом новых проуессоров, в основном, увеличиваются только рабочие частоты — командные множества остаются такими же. Сегодня основное направление в развитии комманд процессора — математика для 3D графики — которая нужна в основном только разработчикам DirectX и видеокарт. Не уверен, что линейная алгебра потребуется для средства передачи звука.

3. Маниакальная борьба за производительность — оптимизации до байта.

СЕГОДНЯ НЕ АКТУАЛЬНО: Вычислительные мощности компьютеров настолько выросли, что намного себе дороже оптимизировать (сколько у тебя весит программа 2 мегабайта или 100 мегабайт, сколько жрет памяти — 1 метр или 50 метров — всем по барабану). А вот глючность никуда не девалась — 20 лет назад бесила пользователей и сегодня пользователей бесит.


Вывод: если проблемы производительности ушли сами собой по течению времени, за чем же ими заниматься?

Не лучше потраченное на это время уделить вопросам стабильности?

Whistler wrote:
> СЕГОДНЯ НЕ АКТУАЛЬНО: Вычислительные мощности компьютеров настолько
> выросли, что намного себе дороже оптимизировать (сколько у тебя весит
> программа 2 мегабайта или 100 мегабайт, сколько жрет памяти — 1 метр или
> 50 метров — всем по барабану).
В данный момент у меня на компьютере 42 процесса. Большая часть занимает
около мегабайта (общий объем занятой памяти 442Мб), всего памяти 1Гб.

Если бы программы занимали хотя бы в два раза больше места — у меня
памяти бы не хватило. И при этом ничего особого на компьютере не стоит.

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

C>Intel C++ — уже много лет параллелит. Там при максимальном уровне
C>предупреждений даже выдается гордая надпись: "xx.cpp(yyy) : (col. nn)
C>remark: LOOP WAS VECTORIZED."

C>В GCC 4.1 тоже векторизация появилась, в 4.2 ее заметно расширят.

Гордая надпись выдается только для циклов типа:
[/code]
for(int i=0;i<n;++i) { a[i]=b[i]; }

Чтобы параллелить такие циклы много ума не надо.
Однако уже для кода:
[/code]
float a[4],b[4];
void f() {
  a[0]=b[0];
  a[1]=b[1];
  a[2]=b[2];
  a[3]=b[3];
}
[ccode]
генерится четыре скалярные инструкции, вместо одной векторной!!! (в версии 9.0)
Вот когда компиляторы будут в состоянии заменять код сортировки пузырьком,
на код параллельной сортирующей сети Бэтчера, или хотябы
максимум из 128 элементов заменять на векторный максимум и цикл:
[/code]
char a[16],b[16];
short s=0;
for(int i=0;i<16;++i) { s+=abs(a[i]-b[i]); }
[ccode]
компилить в:
[asm]
movdqa xmm0,xmmword ptr [a]
psadbw xmm0,xmmword ptr [b]
movd eax,xmm0
...
[/asm]
тогда я соглашусь что параллелит.
В ближайшие 20 лет здесь ничего не изменится, как почти ничего не изменилось за прошлые 15.
Единственное что умеет делать Intel C++, это неплохо предсказывать вероятности переходов в циклах.
А чтобы делать то, о чем я написал выше нужен принципиально иной подход к построению оптимизаторов,
которого не видно даже на горизонте.

C>Вот пример такого "ассемблера":
C>[code]
C>uniform sampler2D coeffsABC;
C>uniform sampler2D coeffsDEF;

C>void main( void )
C>{
C>   // Get the texture coordinates
C>   vec2 st = gl_TexCoord[0].st;

C>   // Read the polynomial coefficients from the textures
C>   vec3 ABC = vec3(texture2D(coeffsABC, st)-0.50196); // 8-bit signed,
C>   vec3 DEF = vec3(texture2D(coeffsDEF, st)-0.50196); // 128/255 -> 0.0

C>   // Construct vectors with powers of u and v
C>   vec3 uv1 = vec3(fract(st*32.0), 1.0);
C>   vec3 u2uvv2 = uv1.xxy * uv1.xyy;

C>   // Calculate the pixel size in (u,v) space for antialiasing
C>   vec4 duvdxy = 32.0*vec4(dFdx(st), dFdy(st));
C>   float stepwidth = 0.5*length(duvdxy);

C>   // Make a checkered pattern to show texel borders
C>   //vec2 cst = floor(mod(st*32.0, 2.0));
C>   //float c = mod(dot(cst, vec2(1.0, 1.0)), 2.0);

C>   // Evaluate the implicit curve polynomial
C>   float f = dot(ABC,u2uvv2) + dot(DEF,uv1);

C>   // Compute the magnitude of the gradient of the polynomial
C>   vec2 gradf = vec2(dot(uv1, vec3(2.0*ABC.x,ABC.y,DEF.x)),
C>     dot(uv1, vec3(2.0*ABC.z,ABC.y,DEF.y)));
C>   float g = inversesqrt(dot(gradf, gradf));

C>   // Set the color to be black when P<=0.0, white otherwise
C>   float a = smoothstep(-stepwidth, stepwidth, f*g);
C>   gl_FragColor = vec4(a, a, a, 1.0);
C>}
C>

Если имелось в виду, что это типа не ассемблер, тогда вот это:

#include <emmintrin.h>

char *p;
__m128i u,v,w1,w2,t;
...
w1=_mm_shufflehi_epi16(u,15);
w2=_mm_shufflelo_epi16(v,7);

_mm_maskmoveu_si128(w1,w2,p);

t=_mm_cmpunord_pd(w1,w2);
...

есть истинный код на чистом C++

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

C>Whistler wrote:
>> СЕГОДНЯ НЕ АКТУАЛЬНО: Вычислительные мощности компьютеров настолько
>> выросли, что намного себе дороже оптимизировать (сколько у тебя весит
>> программа 2 мегабайта или 100 мегабайт, сколько жрет памяти — 1 метр или
>> 50 метров — всем по барабану).
C>В данный момент у меня на компьютере 42 процесса. Большая часть занимает
C>около мегабайта (общий объем занятой памяти 442Мб), всего памяти 1Гб.

C>Если бы программы занимали хотя бы в два раза больше места — у меня
C>памяти бы не хватило. И при этом ничего особого на компьютере не стоит.

Вы неправильно поняли, Вам пытались сказать, что если бы у вас процессы эти занимали всего 200 мегов вместо 400, то Вы бы не порадовались, ибо стоимость разработки этих же 42 процессов на АСМе была бы раз в 10 выше, и софт был бы дико дорогой. Получается, изготовление железа стало проще, чем создание софта.

Ник wrote:
> C>Если бы программы занимали хотя бы в два раза больше места — у меня
> C>памяти бы не хватило. И при этом ничего особого на компьютере не стоит.
> Вы неправильно поняли, Вам пытались сказать, что если бы у вас процессы
> эти занимали всего 200 мегов вместо 400, то Вы бы не порадовались, ибо
> стоимость разработки этих же 42 процессов на АСМе была бы раз в 10 выше,
> и софт был бы дико дорогой.
Во-первых, стоимость софта к стоимости его разработки отношение имеет
весьма непрямое. Во-вторых, если писать на хорошо оптимизированном С/C++
— то коэффициент будет не "10", а сильно меньше.

Здравствуйте, Whistler, Вы писали:
W>
3. Маниакальная борьба за производительность — оптимизации до байта.

W> СЕГОДНЯ НЕ АКТУАЛЬНО: Вычислительные мощности компьютеров настолько выросли, что намного себе дороже оптимизировать (сколько у тебя весит программа 2 мегабайта или 100 мегабайт, сколько жрет памяти — 1 метр или 50 метров — всем по барабану). А вот глючность никуда не девалась — 20 лет назад бесила пользователей и сегодня пользователей бесит.

Программа — да. А вот узкое место, из-за которого все тормозит (У Вас ВСЕ летает? Я Вам завидую, у меня тормоза сплошные везде) нужно оптимизировать насколько это возможно. Да, код формочки глупо обычно оптимизировать. А код кодека, или поисковика по большому объему данных — очень и очень желательно.

W>Вывод: если проблемы производительности ушли сами собой по течению времени, за чем же ими заниматься?

А они правда ушли? Я чего-то не замечаю.

W>Не лучше потраченное на это время уделить вопросам стабильности?

Стабильность — это хорошо. Но и скорость нужно.

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

C>Если бы программы занимали хотя бы в два раза больше места — у меня
C>памяти бы не хватило. И при этом ничего особого на компьютере не стоит.
К сожалению, обычно экономия памяти при помощи кодирования на ассемблере обычно какая-то не такая.
Вот отказ от GC ещё может на это как-то повлиять, а переход на асм совсем не про то.
Скорее надо структуры данных и алгоритмы оптимизировать, а не процедуры на асме кропать

Erop wrote:
> C>Если бы программы занимали хотя бы в два раза больше места — у меня
> C>памяти бы не хватило. И при этом ничего особого на компьютере не стоит.
> К сожалению, обычно экономия памяти при помощи кодирования на ассемблере
> обычно какая-то не такая.
> Вот отказ от GC ещё может на это как-то повлиять, а переход на асм
> совсем не про то.
Вообще-то и говорилось в русле managed+GC vs unmanaged