Тим рассказывает, как фронтьер сильных вычислений в лице геймдев индустрии подомнёт под себя Яндекс с Гуглем и к 2009 году получит >1TFLOPS непрерывно в качестве бесплатного приложения к скринсейверу на HD проекторе. Но счастье будет небесплатным, а в виде 20+ cores, 80+ threads. И как жить с этим, программируя на C++ нельзя.
Объясняется, что язык должен быть lenient (non-strict, насколько я понял - в обсуждении на Lambda-the-Ultimate ссылку дают, id90 - туда же, -- компилятор имеет право редуцировать жадно, если это допустимо; для lazy - явные suspend/eval), чисто функциональный но в возможностью аннотирования side effects, полностью GC, с аккуратно прибитой exception моделью в стиле C#/Java по поводу операторов языка (доступ к элементам массива и т.п.). Сильная аннотация типов, вплоть до nat(m) - натуральное n<m (для индексации массивов, опять же).
Приводится вот такая табличка:
Game Simulation
Numeric Computation
Shading Languages
C++, Scripting
C++
CG, HLSL
CPU Budget
10%
90%
n/a
Lines of Code
250,000
250,000
10,000
FPU Usage
0.5 GFLOPS
5 GFLOPS
500 GFLOPS
Parallelism
Software Transactional Memory
Implicit Thread Parallelism
Implicit Data Parallelism
При этом делается упор на то, что большинство вычислений - существенно функциональные (в смысле минимума side-effects) и распределенные (разные - по-разному).
Performance
When updating 10,000 objects at 60 FPS, everything is performance-sensitive
Modularity
Very important with ~10-20 middleware libraries per game
Reliability
Error-prone language / type system leads to wasted effort finding trivial bugs
Significantly impacts productivity
Concurrency
Hardware supports 6-8 threads
C++ is ill-equipped for concurrency
Дальше объясняется, почему кривой С++, почему крива потоковая модель, построенная на разделении состояния + мониторах. В пример ставится shader languages, в которых параллелизм по данным вполне.
Предлагается аннотировать код (чисто функциональный vs side effects), и использовать модель Software Transactional Memory (composable memory transactions) - недетерминистски упорядоченные наборы атомарных операций.
о, спасибо за развернутый ответ я так понял, что все же не зря начал Haskell учить. хоть вряд ли буду на нем программировать серьезно, но дозу функциональности в кровь пустить не помешает
ну да, к 2009 заткнет за пояс текущий яндекс, да и то только на специальных тестах :) яндекс с гуглем btw параллелизуются на порядки проще. гуглю вон вообще одного mapReduce'a для этого похоже хватает. И код в них проще и его существенно меньше, так шо c++ здесь не проблема. халява в общем :)
no subject
Date: Feb. 5th, 2006 20:08 (UTC)а то у меня PowerPoint отсутсвует
no subject
Date: Feb. 5th, 2006 20:32 (UTC)Но счастье будет небесплатным, а в виде 20+ cores, 80+ threads.
И как жить с этим, программируя на C++ нельзя.
Объясняется, что язык должен быть lenient (non-strict, насколько я понял - в обсуждении на Lambda-the-Ultimate ссылку дают, id90 - туда же, -- компилятор имеет право редуцировать жадно, если это допустимо; для lazy - явные suspend/eval), чисто функциональный но в возможностью аннотирования side effects, полностью GC, с аккуратно прибитой exception моделью в стиле C#/Java по поводу операторов языка (доступ к элементам массива и т.п.).
Сильная аннотация типов, вплоть до nat(m) - натуральное n<m (для индексации массивов, опять же).
Приводится вот такая табличка:
Languages
При этом делается упор на то, что большинство вычислений - существенно функциональные (в смысле минимума side-effects) и распределенные (разные - по-разному).
Дальше объясняется, почему кривой С++, почему крива потоковая модель, построенная на разделении состояния + мониторах.
В пример ставится shader languages, в которых параллелизм по данным вполне.
Предлагается аннотировать код (чисто функциональный vs side effects), и использовать модель Software Transactional Memory (composable memory transactions) - недетерминистски упорядоченные наборы атомарных операций.
Уф, устал.
Четай Lambda-the-Ultimate уже! :)
no subject
Date: Feb. 5th, 2006 20:45 (UTC)я так понял, что все же не зря начал Haskell учить. хоть вряд ли буду на нем программировать серьезно, но дозу функциональности в кровь пустить не помешает
no subject
Date: Feb. 6th, 2006 09:20 (UTC)no subject
Date: Feb. 6th, 2006 11:53 (UTC)no subject
Date: Feb. 6th, 2006 12:53 (UTC)Чего только стоит это высказывание: "When updating 10,000 objects at 60 FPS..."
Не делайте так :)
no subject
Date: Feb. 6th, 2006 19:50 (UTC)no subject
Date: Feb. 9th, 2006 19:17 (UTC)А C++ себя изжил, это так.
Расскажи лучше про правильный лисп как-нибудь.