Каморка

Marmot писал(а):А ваще фигня все это, ядрам работа и так найдется
Одно ядро - антивирус
Второе файрвол
Третье какой-нубудь троян
Четвертое программа пользователя
И т.д. и т.п.
У винды процессов и так уже дох, всем ядрам работа найдется, и без всякого заумного распараллеливания

Ну да, а нам на что жить?

Sturgeon писал(а):

Marmot писал(а):А ваще фигня все это, ядрам работа и так найдется
Одно ядро - антивирус
Второе файрвол
Третье какой-нубудь троян
Четвертое программа пользователя
И т.д. и т.п.
У винды процессов и так уже дох, всем ядрам работа найдется, и без всякого заумного распараллеливания

Ну да, а нам на что жить?

Вы бы лучше AI наконец сделали нормальный, шоб можно было перестать напрягать моск...

Marmot писал(а):

Sturgeon писал(а):

Marmot писал(а):А ваще фигня все это, ядрам работа и так найдется
Одно ядро - антивирус
Второе файрвол
Третье какой-нубудь троян
Четвертое программа пользователя
И т.д. и т.п.
У винды процессов и так уже дох, всем ядрам работа найдется, и без всякого заумного распараллеливания

Ну да, а нам на что жить?

Вы бы лучше AI наконец сделали нормальный, шоб можно было перестать напрягать моск...

Какой вы вредный всё таки. Ну сделаем, а потом?

Sturgeon писал(а):Ну да, а нам на что жить?

Sturgeon писал(а):

Marmot писал(а):

Sturgeon писал(а):

Marmot писал(а):А ваще фигня все это, ядрам работа и так найдется
Одно ядро - антивирус
Второе файрвол
Третье какой-нубудь троян
Четвертое программа пользователя
И т.д. и т.п.
У винды процессов и так уже дох, всем ядрам работа найдется, и без всякого заумного распараллеливания

Ну да, а нам на что жить?

Вы бы лучше AI наконец сделали нормальный, шоб можно было перестать напрягать моск...

Какой вы вредный всё таки. Ну сделаем, а потом?

Sturgeon писал(а):Ну да, а нам на что жить?

Не бойтесь, выживем, будем как овечки пастись под контролем мудрого пастуха, совокупляясь на горных склонах
Счастье для всех!.. Даром! ... (с)

Marmot писал(а):

Stanislav писал(а):

Marmot писал(а):Я надеюсь "PhD студенты от Computer Science" знают что им не надо ждать 2009-10гг а можно использовать процессоры от SUN T2 прямо сейчас?

Как же его использовать, если у него цена от самолета!

Xмм, где можно купить такой дешевый самолет? http://www.sun.com/servers/coolthreads/t5120/

Охххх... фигассе, я за эти деньги куплю 5 серверов обычных...
Особенно впечатлило сравнение с обычным сервером - лицензия на софт 1500USD! Это за CentOS? Виртуализация 4500USD! Это за ХЕН?

Marmot писал(а):А ваще фигня все это, ядрам работа и так найдется
Одно ядро - антивирус
Второе файрвол
Третье - какой-нубудь троян
Четвертое - программа пользователя
Пятое - флеш-реклама в браузере
И т.д. и т.п.
У винды процессов и так уже дох, всем ядрам работа найдется, и без всякого заумного распараллеливания

Все професси нужны - треды всякие важны...

Stanislav писал(а):

Marmot писал(а):А ваще фигня все это, ядрам работа и так найдется
Одно ядро - антивирус
Второе файрвол
Третье - какой-нубудь троян
Четвертое - программа пользователя
Пятое - флеш-реклама в браузере
И т.д. и т.п.
У винды процессов и так уже дох, всем ядрам работа найдется, и без всякого заумного распараллеливания

Все професси нужны - треды всякие важны...

Ну вот кстати если серьёзно - то зачем, всё таки, нужно распараллеливать в такой ситуации? Потому что когда в десктопном/лаптопном проце будет по 500 ядер (а их там будет, выбора то нет), причём разных по тактовой частоте, размеру кеша и даже выполняемым инструкциям, то нитей на всех не хватит если так их распределять. Придётся всё таки распараллеливать Фотошопы, Офисы и прочее, иначе производительность никак не повысить.

Sturgeon писал(а): Ну вот кстати если серьёзно - то зачем, всё таки, нужно распараллеливать в такой ситуации? Потому что когда в десктопном/лаптопном проце будет по 500 ядер (а их там будет, выбора то нет), причём разных по тактовой частоте, размеру кеша и даже выполняемым инструкциям, то нитей на всех не хватит если так их распределять. Придётся всё таки распараллеливать Фотошопы, Офисы и прочее, иначе производительность никак не повысить.

Ок, давайте говорить серьезно, тем более, что эта тема меня тоже сильно интересует.
Ежу понятно что распараллеливать надо, вопрос как это сделать так, что-бы даже VB программисты могли это использовать.
Все эти Erlang-и, Haskell-ы, F#, Fortress-ы, Scala-ы, CUDA, etc, позиционируемые как решение проблемы массового параллелизма совершенно несъедобны для основной массы современных программистов. Так же как и текущий примитивный подход основанный на shared state and locking ...
Пока что у меня создаетя впечатление, что данная проблема не разрешима в принципе, именно поэтому я и написал про AI
T.e. мы должны научится использовать все эти сотни и тысячи ядер совсем по другому

Marmot писал(а):Ну может он где-нибудь и dramatic , а на сервер сайде иметь >500 threads уже давно норма жизни.

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

sz писал(а):

Marmot писал(а):Ну может он где-нибудь и dramatic , а на сервер сайде иметь >500 threads уже давно норма жизни.

Сомнительная какая-то норма.
На двух ядрах 500 потоков будут либо постоянно спать, либо толкаться и не давать друг другу работать.
И то, и другое - непонятно зачем.

Они не спят, они ждут
Ждут ответа из базы данных, ждут пока все данные запишутся на диск, ждут еще какой-нибудь, не зависящей от них фигни.
У нас на один запрос пользователя бывает нужно опросить/записать штук 5-8 различных баз данных, текстовый индех, geo-engine, etc.
Очень часто это можно сделать параллельно...
А ядер у нас, как правило 8, очень редко 4

Marmot писал(а):

Sturgeon писал(а): Ну вот кстати если серьёзно - то зачем, всё таки, нужно распараллеливать в такой ситуации? Потому что когда в десктопном/лаптопном проце будет по 500 ядер (а их там будет, выбора то нет), причём разных по тактовой частоте, размеру кеша и даже выполняемым инструкциям, то нитей на всех не хватит если так их распределять. Придётся всё таки распараллеливать Фотошопы, Офисы и прочее, иначе производительность никак не повысить.

Ок, давайте говорить серьезно, тем более, что эта тема меня тоже сильно интересует.
Ежу понятно что распараллеливать надо, вопрос как это сделать так, что-бы даже VB программисты могли это использовать.
Все эти Erlang-и, Haskell-ы, F#, Fortress-ы, Scala-ы, CUDA, etc, позиционируемые как решение проблемы массового параллелизма совершенно несъедобны для основной массы современных программистов. Так же как и текущий примитивный подход основанный на shared state and locking ...
Пока что у меня создаетя впечатление, что данная проблема не разрешима в принципе, именно поэтому я и написал про AI
T.e. мы должны научится использовать все эти сотни и тысячи ядер совсем по другому

Оговорюсь сразу, что речь идёт про thread-level parallelism как наиболее актуальный на данный момент. Здесь несколько путей обойтись без AI:

- первый и самый пока распространённый - это использование скрытой параллельности при программировании. Т.е. специально создают параллельные конструкции типа for или if, операции при обработке массивов и т.д. Они уже сами разбираются как распараллелить, только данные им дай. .NET это уже умеет делать, многие framework'и уже в продаже или разрабатываются. От программиста требуется их использовать по мере надобности. Не фонтан, конечно, но хоть как то распараллелить помогает.

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

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

- повышать эффективность работы параллельных машин, т.е. понижать их энергопотребление и более эффективно распределять нити по ядрам.

Лично я занимаюсь последним. Программерам - искренне сочувствую

Sturgeon писал(а):
- первый и самый пока распространённый - это использование скрытой параллельности при программировании. Т.е. специально создают параллельные конструкции типа for или if, операции при обработке массивов и т.д. Они уже сами разбираются как распараллелить, только данные им дай. .NET это уже умеет делать, многие framework'и уже в продаже или разрабатываются. От программиста требуется их использовать по мере надобности. Не фонтан, конечно, но хоть как то распараллелить помогает.

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

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

OMFG, неужели в унверситетах работают такие наивные люди...
Этож смешно слышать: "повышать квалификацию", "переписывать с нуля" ...

Parallel.For из .NET-a это вообще насмешка судьбы, неявный паралелилизм, требующий явной синхронизации

Sturgeon писал(а): - повышать эффективность работы параллельных машин, т.е. понижать их энергопотребление и более эффективно распределять нити по ядрам.

Лично я занимаюсь последним. Программерам - искренне сочувствую

Ага, выбрали то, что полегче, понятненько...

А я вот что думаю.
Эти многоядерные процессоры в персоналках обещали еще год назад.
Ну и где они?

Есть у меня большое подозрение, что не пойдет многоядерность. Слишком много проблем. С кешем проблемы, с программированием проблемы.
А если это место на кристалле просто пустить под кеш, производительность прирастет не менее ощутимо, чем от тыщи ядер. Причем сразу прирастет. Без всякого перепрограммирования.

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

sz писал(а):А я вот что думаю.
Эти многоядерные процессоры в персоналках обещали еще год назад.
Ну и где они?

Хм, может мы на разных планетах живем, но 2 ядра уже норма во всех новых лептопах и десктопах выпуска 2007-2008 годов. 4 тоже вполне можно найти тем кому 2 уже мало. Через год думаю аналогичное будет справедливо для 4 vs. 8. Большая проблема о которой мало кто говорит это то что сегодняшние операционные системы еще очень плохо приспособлены для работы на железках с количеством ядер больше 8-16. Требуются серьезные доработки в scheduler, memory allocator итд.

А по поводу программирования этого дела, есть вполне традиционные модели, которые позволяют поэтапно переходить от последовательного к паралельному программированию без полного переписывания софта и большого гемороя с локингом (например модель thread pool). Магического роста производительности конечно не получится но с разумными затратами труда эффект будет хороший.

Прирост производительности от увеличения размера кеша будет только до той поры пока его размер меньше чем working set. Я так подозреваю что на большинстве прикладных задач сегодняшние типичные размеры в несколько мегабайт вполне достаточны. Увеличить кеш в 10 раз можно, но думается что положительный эффект от этого будет в пределах 10-15%.

-Maxim

Sturgeon писал(а):

Marmot писал(а):

Sturgeon писал(а):

Marmot писал(а):А ваще фигня все это, ядрам работа и так найдется
Одно ядро - антивирус
Второе файрвол
Третье какой-нубудь троян
Четвертое программа пользователя
И т.д. и т.п.
У винды процессов и так уже дох, всем ядрам работа найдется, и без всякого заумного распараллеливания

Ну да, а нам на что жить?

Вы бы лучше AI наконец сделали нормальный, шоб можно было перестать напрягать моск...

Какой вы вредный всё таки. Ну сделаем, а потом?

Sturgeon писал(а):Ну да, а нам на что жить?

Как что? AI поддерживать!!! Чинить, переустанавливать итд.

-Maxim