Программирование - это просто

[sami]

Parallel computing with graphics processing units for high-speed Monte Carlo simulation of photon migration
Может быть эта задача покажется интереснее

Abstract. General-purpose computing on graphics processing units
GPGPU is shown to dramatically increase the speed of Monte Carlo simulations of photon migration.
In a standard simulation of time-resolved photon migration in a semi-infinite geometry, the proposed methodology executed on a low-cost graphics processing unit GPU is a factor 1000 faster than simulation performed on a single standard processor. In addition, we address important technical aspects of GPU-based simulations of photon migration. The technique is expected to become a standard method in Monte Carlo simulations of photon migration. © 2008 Society of Photo-Optical Instrumentation Engineers.

Да мало ли где кто и что там "обкатывает"! У меня своя программа, и я буду исходить от неё. Подобных псевдо-сенсаций на моей памяти было много - все канули в лету.

Опять хвастаетесь собственным безраличием.

Вот именно, Вы это очень правильно подметили. Вы будете переписывать свой код так, чтобы размер стэковой памяти + размер динамической памяти + размер кодовой части не превышал 256 Kb? Можете? А всё что сверх того, надо запросить у головного процесса в процессе счёта, оформив запрос сооветсвующим образом. При этом, как то, не понятно как, обяснить головному процессу, какие именно данные из сотен тысяч, Вам нужны? Вы готовы к этому? Попробуйте хоть одну свою серьёзную программу подвести под эти требования!

Ну-ну, вперёд и с песней.

Откуда такие ограничения? Писали софт для домофона?
З.Ы. Если потребуется, то я знаю как вообще без стека обойтись. Да и 256Кб - это довольно много. Любую программу в них не ужать, но попытаться можно. Не страшно.

Я, знаете ли, говоря о рендеринге и визуализации, НИГДЕ не говорил о Вашем CUDA!

А я говорил о счете. И ни слова о рендеринге и визуализации. С чего Вы взяли, что я имею отношение к рендерингу и визуализации?

 

[SCTRWD]

Parallel computing with graphics processing units for high-speed Monte Carlo simulation of photon migration
Может быть эта задача покажется интереснее

Да, господи, путей ускорения кода Монте-Карло не счесть. Естественно, в ущерб точности результатов. Та же дискретизация геометрии даёт дикий прирост производительности.(что активно используется в наиболее распространённых программах облучения раковых опухолей). Но в серьёзных приложениях(читай военных ), это не прокатывает.

 

[sami]

Да, господи, путей ускорения кода Монте-Карло не счесть. Естественно, в ущерб точности результатов. Та же дискретизация геометрии даёт дикий прирост производительности.(что активно используется в наиболее распространённых программах облучения раковых опухолей). Но в серьёзных приложениях(читай военных ), это не прокатывает.

Вы прочитали в статье, что они добились результата дискредитацией геометрии?
Цитату в студию!

Вот еще ссылка для любознательных
http://www.cse.chalmers.se/edu/course/TDA9...ian-shortp2.pdf

Obsidian is a GPGPU language embedded in Haskell. The goal is to simplify GPGPU programming by raising the level of abstraction but still offer control of the details necessary to write efficient programs.

Вот ссылка на сайт CUDA.
http://www.nvidia.co.uk/object/cuda_home_uk.html#state=home

Пусть любознательные посмотрят области применения.

 

[SCTRWD]

Опять хвастаетесь собственным безраличием.

Не безраличием, а знанием.

Откуда такие ограничения? Писали софт для домофона?

Документация по GPU и Cell.

З.Ы. Если потребуется, то я знаю как вообще без стека обойтись. Да и 256Кб - это довольно много. Любую программу в них не ужать, но попытаться можно. Не страшно.

Охотно верю, но я не хочу даже ПЫТАТЬСЯ, и я не ХОЧУ это проверять и ПОВТОРЯТЬ, и я не ХОЧУ сидеть и извращаться, и отлаживаться. Кстати, я - это коллектив в несколько десятков человек, каждый ОЧЕНЬ хорош в своей области, и НЕ желает НИЧЕГО знать о других.

И уж тем более, мы не хотим делать то, что через год станет НИКОМУ не нужным хламом.

А я говорил о счете. И ни слова о рендеринге и визуализации. С чего Вы взяли, что я имею отношение к рендерингу и визуализации?

Из Ващего поста, вестимо.

 

[sami]

Отдельное внимание MapReduce на GPU

The MapReduce interface is a software framework implemented by Google to support parallel computations on the datasets. This paper describes a framework built around the Map Reduce abstraction, which allows application developers to focus on their application, while enabling high performance GPU implementation.

Speed Up 150x

Не безраличием, а знанием.

Смотрим ниже выделенное ))) (это называется безразличие).

Документация по GPU и Cell.

Цитату в студию.

Охотно верю, но я не хочу даже ПЫТАТЬСЯ, и я не ХОЧУ это проверять и ПОВТОРЯТЬ, и я не ХОЧУ сидеть и извращаться, и отлаживаться. Кстати, я - это коллектив в несколько десятков человек, каждый ОЧЕНЬ хорош в своей области, и НЕ желает НИЧЕГО знать о других.

На работу, как на службу!

И уж тем более, мы не хотим делать то, что через год станет НИКОМУ не нужным хламом.

Не буду комментировать. Пишите на чем знаете, что ж Вы в этой ветке делаете?

Из Ващего поста, вестимо.

Из которого?

 

[SCTRWD]

Вы прочитали в статье, что они добились результата дискредитацией геометрии?
Цитату в студию!

Где я об этом говорил?!

Я говорил об одной из возможностей ускорения за счёт "дискретизации"(внимательно так слово пишем , дискредитация - это немного из другой оперы :lol: ) геометрии для задач радиотерапии.

 

[sami]

Где я об этом говорил?!

Я говорил об одной из возможностей ускорения за счёт "дискретизации"(внимательно так слово пишем , дискредитация - это немного из другой оперы :lol: ) геометрии для задач радиотерапии.

читал по диагонали, бывает)))

Есть работы на CUDA по аналитически заданным поверхностям. Тоже с нехилым приростом.

 

[SCTRWD]

читал по диагонали, бывает)))

Бывает...

Есть работы на CUDA по аналитически заданным поверхностям. Тоже с нехилым приростом.

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

 

[sami]

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

Вы в каком веке программируете?
Прирост производительности за счет целочисленной арифметики )))

Не безраличием, а знанием.
...
Кстати, я - это коллектив в несколько десятков человек, каждый ОЧЕНЬ хорош в своей области, и НЕ желает НИЧЕГО знать о других.

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

и НЕ желает НИЧЕГО знать о других.

 

[SCTRWD]

Вы в каком веке программируете?
Прирост производительности за счет целочисленной арифметики )))

А что, что-то изменилось? Вы вообще в курсе сколько и какая арифметика требует? Если нет, советую изучить. Реальные компании(типа Adobe), за такие алгоритмы целое состояние платят, вообще-то...

 

[sami]

А что, что-то изменилось? Вы вообще в курсе сколько и какая арифметика требует? Если нет, советую изучить. Реальные компании(типа Adobe), за такие алгоритмы целое состояние платят, вообще-то...

Без комментариев. Что-то изменилось с какого года?

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

 

[SCTRWD]

Без комментариев. Что-то изменилось с какого года?

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

Не устаю поражаться! Ну вы даёте, если честно. Среди программеров давно распространеннны таблицы, какая операция, сколько занимает. Операции с целыми числами - самая дешовая операция(кроме деления(и взятия остатка) - это САМАЯ дорогая операция, даже среди операндов с плавающей точкой(именно поэтому всегда выгодней помножить на 0.5 чем поделить на 2).

 

[sami]

Оглянитесь по сторонам! Я понимаю, лень и некогда, но половина дедовских трюков морально устарела, и мало того не дает прироста производительности, так еще и тормозит!

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

Не устаю поражаться! Ну вы даёте, если честно. Среди программеров давно распространеннны таблицы, какая операция, сколько занимает. Операции с целыми числами - самая дешовая операция(кроме деления(и взятия остатка) - это САМАЯ дорогая операция, даже среди операндов с плавающей точкой(именно поэтому всегда выгодней помножить на 0.5 чем поделить на 2).

ДАВНО. Это было ДАВНО.

 

[SCTRWD]

Оглянитесь по сторонам! Я понимаю, лень и некогда, но половина дедовских трюков морально устарела, и мало того не дает прироста производительности, так еще и тормозит!

Какие из описанных мной устарели?

Вместо этого работаю совершенно другие трюки. Оптимизация под кэши, например. Минимизация условного ветвления...

Вы уверенны, что работают? Целочисленная арифметика ГАРАНТИРОВАННО даёт прирост производительности, всегда и везде. А вот оптимизация под кэши, это - химера. Может сработать на плюс, а может сработать и на минус.

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

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

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

И С и C++, кстати - в этом смысле, просто враг компилятора. Из за своей "гибкости", они не дают компилятору сформировать оптимальный код.

 

[sami]

Какие из описанных мной устарели?

Это Вы уж сами проверьте.

Вы уверенны, что работают? Целочисленная арифметика ГАРАНТИРОВАННО даёт прирост производительности, всегда и везде. А вот оптимизация под кэши, это - химера. Может сработать на плюс, а может сработать и на минус.

Ой, Вы уж проверьте свои гарантии. Целочисленная арифметика может улучшить производительность на пару процентов, а оптимизация под кэши - в десятки раз!

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

Может все же почитаете? Или так и будете опираться на знания, актуальные в середине прошлого века)))

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

И С и C++, кстати - в этом смысле, просто враг компилятора. Из за своей "гибкости", они не дают компилятору сформировать оптимальный код.

Камни давно уже выполняют не машинный код. Отстали Вы капитально от жизни.

 

[SCTRWD]

Это Вы уж сами проверьте.

То есть, ответа нет...

Ой, Вы уж проверьте свои гарантии. Целочисленная арифметика может улучшить производительность на пару процентов, а оптимизация под кэши - в десятки раз!

Это, конечно, зависит от задачи, но Ваш любимый X-сервер или Windows использует именно целочисленные алгоритмы при отрисовке примитивов, уж поверьте(или проверьте)

Может все же почитаете? Или так и будете опираться на знания, актуальные в середине прошлого века)))

Почитаете что?

Камни давно уже выполняют не машинный код. Отстали Вы капитально от жизни.

Удивили, если честно. Что же тогда "выполняют" камни? Вы хоть сто раз извернитесь, и напридумывайте хоть сто языков, "КАМНИ" будут делать одно и то же.

 

[sami]

Вот я Вам что посоветую: Вы мне не верьте наслово. А возьмите и поставьте эксперимент. Тупой до безобразия:

Возьмите и напишите алгоритм умножения матриц: один раз на ассемблере (можно целочисленно), а второй раз на C++, или Delphi, неважно. Но в алгоритме на высокоуровневом языке проведите оптимизцию под кэш.

А потом скормите этим алгоритмам матрицы размеров в мегабайт 20-40.

10ти или более кратный проигрыш ассемблера гарантирую
Даже SSE ассемблер не спасет.

Уверен, что полученный опыт с успехом примените в работе, так что время зря не потеряете!

То есть, ответа нет...

Хорошо. Целочисленная арифметика больше не рулит. Остальное - чтоб я знал, что Вы еще используете.

Это, конечно, зависит от задачи, но Ваш любимый X-сервер или Windows использует именно целочисленные алгоритмы при отрисовке примитивов, уж поверьте(или проверьте)

Это Вы видать почерпнули из книжки "Программирование компьютерной графики в Windows 95". Примитивы рисует не Windows, а железо.

Почитаете что?

Спецификацию на камни.
Да уже не важно, можете не читать. Главное побольше писать )))

Удивили, если честно. Что же тогда "выполняют" камни? Вы хоть сто раз извернитесь, и напридумывайте хоть сто языков, "КАМНИ" будут делать одно и то же.

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

 

[SCTRWD]

Вот я Вам что посоветую: Вы мне не верьте наслово. А возьмите и поставьте эксперимент. Тупой до безобразия:

Возьмите и напишите алгоритм умножения матриц: один раз на ассемблере (можно целочисленно), а второй раз на C++, или Delphi, неважно. Но в алгоритме на высокоуровневом языке проведите оптимизцию под кэш.

А потом скормите этим алгоритмам матрицы размеров в мегабайт 20-40.

10ти или более кратный проигрыш ассемблера гарантирую

Господи, разговор ни о чём. Случись в Вашем алгоритме условный переход и вся Ваша оптимизация пойдёт лесом.

Или НЕ пойдёт. Или пойдёт, но при других данных. Или пойдёт, но при других размерах данных. Или пойдёт/не пойдёт на компьютере пользователя. Или пойдёт/не пойдёт на компьютере пользователя, если он одновременно запустил Photoshop, И Illustrator? И т.д. и т.п. Вы готовы выпускать полноценное, коммерческое приложение в таких условиях?

Хорошо. Целочисленная арифметика больше не рулит.

Ну, не знаю, где Вы ТАКОЕ черпаете.

Это Вы видать почерпнули из книжки "Программирование компьютерной графики в Windows 95". Примитивы рисует не Windows, а железо.

Действительно что, нафиг нам тогда вообще Windows нужен, железа хватит за глаза :lol:

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

Это у нас камни вдруг стали интерпретировать? Круто!

 

[sami]

Господи, разговор ни о чём. Случись в Вашем алгоритме условный переход и вся Ваша оптимизация пойдёт лесом.

А Вы думаете, что оптимизацию под кэш можно сделать без условного перехода?

Или НЕ пойдёт. Или пойдёт, но при других данных. Или пойдёт, но при других размерах данных. Или пойдёт/не пойдёт на компьютере пользователя. Или пойдёт/не пойдёт на компьютере пользователя, если он одновременно запустил Photoshop, И Illustrator? И т.д. и т.п. Вы готовы выпускать полноценное, коммерческое приложение в таких условиях?

Я занимаюсь разработкой коммерческих приложений. Фотошоп им не помеха. Лишь бы виртуальную память не выкушал всю.

Ну, не знаю, где Вы ТАКОЕ черпаете.

Я просто много гляжу по-сторонам. Недостаточно много, хотелось бы больше.

Действительно что, нафиг нам тогда вообще Windows нужен, железа хватит за глаза

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

Это у нас камни вдруг стали интерпретировать? Круто!

Да Вы покрутитесь где-нибудь, спросите у кого-нибудь, только не у тех 10 человек, они походу такие же дремучие.

А вообще, давно ли Вы были на тематических конференциях, читали ли документацию Intel, AMD? Хотя бы не документацию, а рекламные анонсы?

 

[SCTRWD]

А Вы думаете, что оптимизацию под кэш можно сделать без условного перехода?

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

Я занимаюсь разработкой коммерческих приложений. Фотошоп им не помеха. Лишь бы виртуальную память не выкушал всю.

У Вас есть данные о производительности Фотошоп в данных условиях? Упала ли она(именно для Фотошоп), осталась ли на прежнем уровне?

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

Ой, да конечно. Только вот железо не умеет отрисовывать окна и их содержимое. Оно делает только то что Windows, или X-сервер им скажет.

Да Вы покрутитесь где-нибудь, спросите у кого-нибудь, только не у тех 10 человек, они походу такие же дремучие.

А вообще, давно ли Вы были на тематических конференциях, читали ли документацию Intel, AMD? Хотя бы не документацию, а рекламные анонсы?

Кто те 10 человек, мне аж самому интересно. Но мне как то не надо читать документацию, чтобы знать базовые вещи. Например то, что процессор НИЧЕГО не знает, и НЕ должен знать, о том НА КАКОМ языке написана программа, которую он исполняет. Он видит только ассемблерный код и всё.