Здравствуйте, c-smile, Вы писали:
CS>Ну если бы все сервисы что работают сейчас в Windows "в заду" ушли на свои собственные ядра никому плохо бы не было.
Они в основном спят. А те что не спять становятся в очередь к ресурсам вроде кэша, памяти, дестких дисков, каналов вода/вывода...
CS>Тако ж apache явно просится на такую модель. Нет?
Ага. Только на 80 камнях он будет работать не лучше чем на 8. Пока что даже Виндовс в штатном варианте не держит более 8. Так что тут прийдется очень многое переписать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mamut, Вы писали:
M>Что, собственно, приводит к следующему вопросу: А что у нас, собственно, способно прямо сейчас, убудчи запущенным на таком монстре, воспользоваться такой мощью? И что сможет в ближайшие пять лет?
Сейчас ровным счетом ничего. Даже серверные продукты теряют эффективность при куда меньшем количестве камней.
Причем чтобы изменить ситуацию программы нужно будет писать просто по другому. Они должны быть рассчитаны на массовый параллелизм. И параллелизм для 8 камней не тоже самое что для 80. Но исследований море. Так что к тмому времени когда у всех (специально для любителей придраться к словам... у всех означает "у большинства") будут на столе такие камни. А это будет не скоро.
А возможно через года 3 будет прорыв в некой области и про многоядерность снова забудут на много лет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Учитывая их время жизни, это непрерывный процесс
VD>Непрерывный процесс — это эволюция. Тут же им прийдется попотеть. Я пока что не видел ни одной игрушки действительно ускоряющейся от наличия второго камня. А вот револющии — это всегда прерывание и надолго.
Я имел в виду что время жизни игры очень маленькое, и поэтому игры обычно первыми и подхвтывают новые аппаратные возможности.
Сейчас практически все большие игры пишутся с учетом распаралеливания, так как у нового поколения игровых приставок процессоры многоядерные.
VD>Уверен, что под такую революцию пролезут новые игроки. Старые как всегда ее проспят. VD>Так было уже не раз. Тот же ФарКрай, например. Но там революция была мизерная. А тут... надо менять архитектуру всего приложения.
Да ничего там сильно менять не надо, в играх полно вещей которые естественно паралелить.
VD>Но тут куча проблем. Ведь код должен одинаково хорошо работать и на 1 и на 80 процессорах. А это без автоматизации невозможно. Тут нужны специальные языки и компиляторы (рантаймы). Нужны новые подходы. Новые алгоритмы. Те работающие догмы что были в однопроцессорном мире будут выброшены на помойку и народ будет по новому изобретать велосипед.
С 80 процессорами да придется делать по другому, да и то не все игры, например те же серверные онлайн игры хоть завтра можно переводить хоть на 1000 ядерный камень. А для 4 — 8 ядер (максимум по моему что угрожает в ближайшие пять лет) у любой игры есть что распаралелить и без новых языков и технологий.
VD>Но уверен, что бабок в индустрии на это хватит. Так что тут скорее надо Интелу стараться чтобы заставить нас купить эти 80-тикамневые процессор. А я лично пока вижу мало толку даже в двух камнях. Так что им прийдется продовать 80х по ценам таким же или ниже чем 1х.
Так если не найдут способ увеличить частоту (хотя и это временная отсрочка, скорость света никто ни отменял ) распаралеливание неизбежно.
Здравствуйте, Курилка, Вы писали:
FR>>Учитывая их время жизни, это непрерывный процесс FR>>Так что преимуществами скорее всего первыми они и воспользуются.
К>Только вот примеров особо пока не видно К>Хотя Тим Свини вроде напирал на concurrency.
Это он впереди паровоза бежит
Для 2 — 8 ядер никаких новых языков и технологий не нужно.
Здравствуйте, Mamut, Вы писали:
M>Коротко говоря: в течение пяти лет Интел предлагает интегрировать невероятное количество процессоров на одном чипе (80 в прототипе) и объединить каждый с собственной памятью.
M>Что, собственно, приводит к следующему вопросу: А что у нас, собственно, способно прямо сейчас, убудчи запущенным на таком монстре, воспользоваться такой мощью? И что сможет в ближайшие пять лет?
Не очень понял: речь идёт о способностях ОС или об используемых алгоритмах? Ну, если ОС — то пока нет аппаратуры о ней и говорить не надо: всё-таки они аппаратно зависимые.
Что касается алгоритмов, то если .NET и пул потоков там нормально будут работать, то я готов дать хоть сейчас код, который сработает нормально (в сложной задаче) на 1500 потоках. Конечно, до пиковой производительности там будет далековато, потому что есть операции, которые исполняются в основном последовательно. Тут видимо уже речь о встраивании в обычные компьютеры векторного подхода и т.п.
И вообще, я не понимаю, (ссылок не читал), почему они будут с собственной памятью? Это неэффективно, строить ccNUMA на одном кристале, когда это явно SMP.
Здравствуйте, Guard, Вы писали:
G>Здравствуйте, Mamut, Вы писали:
M>>Что, собственно, приводит к следующему вопросу: А что у нас, собственно, способно прямо сейчас, убудчи запущенным на таком монстре, воспользоваться такой мощью? И что сможет в ближайшие пять лет?
G>здесь
Здравствуйте, FDSC, Вы писали:
FDS>Что касается алгоритмов, то если .NET и пул потоков там нормально будут работать, то я готов дать хоть сейчас код, который сработает нормально (в сложной задаче) на 1500 потоках. Конечно, до пиковой производительности там будет далековато, потому что есть операции, которые исполняются в основном последовательно.
Забыл сказать, что за задача: расчёт стержневой конструкции на прочность (одна из трудоёмких частей заключает в себе расчёт каждого стержня, который можно проводить отдельно для каждого стержня, при этом сам этот расчёт довольно хорошо параллелится на 13 потоков). В принципе, думаю МКЭ то же неплохо распараллеливается, хотя уже на векторном, а не на скалярном.
Здравствуйте, VladD2, Вы писали:
VD>А возможно через года 3 будет прорыв в некой области и про многоядерность снова забудут на много лет.
В какой? (Просто сильно интересно)
Здравствуйте, FR, Вы писали:
FR>Я имел в виду что время жизни игры очень маленькое, и поэтому игры обычно первыми и подхвтывают новые аппаратные возможности.
Ты путашь игры и их движки. Игры действительно живут как феерверк. А движки эволюционируют годами. Тот же Q4 эволюционировал с Дума. Уж точно с Q1. В бетах Doom 3 были нехилые куски из Q3.
FR>Сейчас практически все большие игры пишутся с учетом распаралеливания, так как у нового поколения игровых приставок процессоры многоядерные.
Языком они пишутся. Да и твои представления о консольных системах очень поверхносные. Там не процессоров много. Тот же Целл это скорее один процессор с кучей сопроцессорв.
В общем, факт в том что нет ни одной игрушки получающей реальное приемущество от второго камня. Хотя, сам понимаешь, по уму обязаны получать. Вопли о параллелизме были еще во времена Q2. Но воз и ныне там.
FR>Да ничего там сильно менять не надо, в играх полно вещей которые естественно паралелить.
Кон надо менять. Ладно мне надоело. Все равно ты будешь из приципа спорить с каждым моим словом. Спорь дальше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexeiz, Вы писали:
A>Нужны языки программирования и библиотеки, облегчающие написание многопоточного кода. A>Могу сказать, что есть для C++.
STFI OpenMP — существует уже давно. Поддерживается компилерами от интела, мелкософта и GNU (gcc 4.1+)
A>Futures обсуждаются для включения в стандарт C++.
Пфе, "жалкое подобие левой руки". По крайней мере, по сравнению с OpenMP
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, Дьяченко Александр, Вы писали:
VD>>А возможно через года 3 будет прорыв в некой области и про многоядерность снова забудут на много лет. ДА>В какой? (Просто сильно интересно)
Я не гадалка. Я просто допускаю такую возможность. Темболее что подбное уже не раз случалось.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FDSC, Вы писали:
FDS>Влад, что смешного? Может объяснишь...
Улыбнула наивность. Уверяю тебя, что даже на 16 процессоров эффективное распараллеливание на сегодны — это очень солжная задача. А уж на 1500 просто фантастика. А в дотнете практически нет средств поддержки массового параллелизма (как и в Виндовс/Линукс в целом). Так что появление 80-процессорых камней неизбежно приведет к революции в средствах разрабокти. И забавно, что бывшие аутсайдеры — функциональные языки — могут оказаться очень даже в фаворе, так как неизменяемость позволяет автоматизировать распараллеливание на уровне алгоритмов. Вот только для этого еже нужно тонну работы сделать. Лично я незнаю ни одного ЯП с автоматическим распараллеливанием вычислений. Тут пока одна теория.
Человек же на таких объемах уже совсем справиться не сможет. Отдельные алгоритмы конечно можно будет распараллелить, но в целом сложность будет такая, что никто за это не возьмется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 0xDEADBEEF, Вы писали:
A>>Futures обсуждаются для включения в стандарт C++. DEA>Пфе, "жалкое подобие левой руки". По крайней мере, по сравнению с OpenMP
Собственно, сравнение futures с OpenMP неправомерно. У них разное предназначение. Futures задумывались для облегчения написания асинхронного кода. С помощью такой абстракции как futures, асинхронное выполнение сводится к небольшому количеству телодвижений:
std::thread_pool launch_in_pool;
std::future<std::vector<int>> f3 = launch_in_pool(std::bind(h, 100)); // асинхронный вызов h(100)
// ... делаем другие вещи, пока f3 выполняется
std::vector<int> v = f3(); // ждём окончания исполнения f3 и возвращаем его результат
CS>>Тако ж apache явно просится на такую модель. Нет?
VD>Ага. Только на 80 камнях он будет работать не лучше чем на 8.
Гхм. А аргументы какие? Апач активно юзает многопоточность. Те он на ней построен. Больше процессоров — быстрее будут исполняться всяческая CGI хренотень, которой запускается много потоков (по потоку на клиента) и каждому из которых надо много CPU. Будет одновременно обрабатываться 80 клиентов скриптами на каком нить перле — будут загружены все 80 процессоров. Будет одновреенно 1000 клиентов сидеть (довольно скромная цифра для веб сервера кстати) — тем лучше.
VD>Пока что даже Виндовс в штатном варианте не держит более 8. Так что тут прийдется очень многое переписать.
w2k3 Datacenter держит 32. Так что 4 CPU или скока там для какой нить ХР — ограничение скорее маркетинговое.
Много процессоров надо тем кому надо много процессорного времени. В "быту" это мультимедиа, архивация, меньше это нужно играм (которые вобщето в последнее время на 3D нагрузку только дают в основном). Первые два варианта давно затачиваются под многопроцессорность — многие видео кодеки и архиваторы умеют распараллеливаться. Игры — хз. Разве что каждого NPC и самого игрока будут обсчитывать разные потоки. Еще можно вспомнить всякие технологии типа распознавания текста/речи — так тут параллелизм — это их родное. Еще можно вспомнить терминальные решения — это когда сидят 50 юзеров через терминалы на одной винде и работают в вордах/ехелях. Там вообще рай для многопроцессорных систем.
D:\Program Files\Far>icl.exe /?
Intel(R) C++ Compiler Help
==========================
...blablabla...
/Qtcheck generate instrumentation to drive the Intel Thread
Checker to detect multi-threading bugs in programs
written using Windows or POSIX Threads
/Qopenmp enable the compiler to generate multi-threaded code
based on the OpenMP directives
/Qopenmp_profile link with instrumented OpenMP runtime library to
generate OpenMP profiling information for use with the
OpenMP component of the VTune(TM) Performance Analyzer
/Qopenmp_stubs enables the user to compile OpenMP programs in
sequential mode. The openmp directives are ignored and
a stub OpenMP library is linked (sequential)
/Qopenmp_report{0|1|2} control the OpenMP parallelizer diagnostic level
/Qparallel enable the auto-parallelizer to generate multi-threaded
code for loops that can be safely executed in parallel
code for loops that can be safely executed in parallel
...blablabla...
Ах да.. для .Net еще нету аналогичного лисапеда
Кстати я например вообще всю жизнь чисто для себя старался распараллеливать все что можно. Просто например потому что так интереснее
Здравствуйте, Курилка, Вы писали:
К>По поводу этой семейки посмотри J, там по сути SIMD на уровне языка получается, поэтому параллелить — это самое логичное.
Хм, а вот чисто гипотетисски интересно ...
Имеем простой код.
*: 1 2 3 4
1 2 9 16
Имеем процессор Pentium. Самый первый в котором появились два целочисленных конвеера.
Использует ли J эти два конвеера или нет ? Насколько я помню, для того чтобы использовались оба конвеера, необходимо специфическая последовательность ассемблерных команд. J же вроде интерпретатор ?
Имеем Dual Core. Распараллелится ли ?
Иммем Intel 80-Core Super-puper Processor. Тот же вопрос.
Или допустим большая числодробилка на Erlang, но написана студентами в одном потоке. Как поведут себя вычисления в этом случае ?
Здравствуйте, alexeiz, Вы писали:
A>Собственно, сравнение futures с OpenMP неправомерно.
Согласен. Futures никак нельзя применить для того чтобы распараллелить код написанный "непараллельным" способом. А вот OpenMP — можно.
A>У них разное предназначение. A>Futures задумывались для облегчения написания асинхронного кода.
Я поглядываю с достаточно большим интересом на futures еще со времени когда про них начал говорить Саттер (где-то с год назад). В первую очередь потому, что при помощи их можно абстрагировать задачи предполагающие асинхронность — не только вычисления, но и ввод-вывод. Например, можно выразить сокетный select() как future.
Но у них есть проблема — futures никак не абстрагируют конкурентный доступ. Также, на данный момент нет никакой возможности (в рамках std::thread, который есть "причесанный" boost::thread) дождаться завершения N futures.
Мне кажется, что когда настанет время большого количества ядер (от 32-х), появится чип — "параллелизатор", который будет искать подходящие паттерны в однопоточном коде и распараллеливать их автоматически... То есть, делать примерно то же самое, что делает OpenMP в "ручном" режиме.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
К>>Хотя Тим Свини вроде напирал на concurrency.
VD>Извини, что за Свин и накого он написал?
