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

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

_>>Улыбнуло:
_>>

640 cores should be enough for anybody!

R>По некоторым авторитетным прогнозам это нас ждёт в очень ближайшем будущем.
R>Так что лучше не улыбаться, а учиться создавать масштабируемые системы
R>

Учиться?
У меня не получается писать однопоточные приложения с 2000 года -- все мои приложения содержат больше одного потоа выполнения.
Что я делаю не так?

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

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

_>>>Улыбнуло:
_>>>

640 cores should be enough for anybody!

R>>По некоторым авторитетным прогнозам это нас ждёт в очень ближайшем будущем.
R>>Так что лучше не улыбаться, а учиться создавать масштабируемые системы
R>>

ZEN>Учиться?

Да, батен'ка: учиться, учиться и еще раз учиться!

ZEN>У меня не получается писать однопоточные приложения с 2000 года -- все мои приложения содержат больше одного потоа выполнения.
ZEN>Что я делаю не так?

многопоточные приложения != масштабируемые системы

ZEN>Диспетчеризация потоков выполнения на нескольких физических процессорах -- это прерогатива исключительно операционной системы и/или VM. Так что перекладывать всю ответственность за эффективность функционирования приложения на прикладного программиста -- моветон.

Да, программистам давно пора снять с себя всяку ответственность за глючность, ресурсоемкость и тормознутось программ. Поддерживаю!

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

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

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

_>>>Улыбнуло:
_>>>

640 cores should be enough for anybody!

R>>По некоторым авторитетным прогнозам это нас ждёт в очень ближайшем будущем.
R>>Так что лучше не улыбаться, а учиться создавать масштабируемые системы
R>>

ZEN>Учиться?
ZEN>У меня не получается писать однопоточные приложения с 2000 года -- все мои приложения содержат больше одного потоа выполнения.
ZEN>Что я делаю не так?

Это совершенно ничего не значит. Вполне возможно, что эти программы будут работать значительно медленее на многопроцессорной машине, чем на однопроцессорной. Количество потоков тут совершенно ни при чём.
Есть две совершенно разные вещи, между которыми пропасть. Их надо строго разделять.
1. Многопоточность на одном ядре
2. Многопоточность на множестве ядер

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

ZEN>Диспетчеризация потоков выполнения на нескольких физических процессорах -- это прерогатива исключительно операционной системы и/или VM. Так что перекладывать всю ответственность за эффективность функционирования приложения на прикладного программиста -- моветон.

Это всё равно, что сказать "TCP/IP стек — прерогатива операционной системы, поэтому можно *любым* образом использовать API сокетов, и ты получишь эффективную программу". Бред! Надо много знать про реализацию сокетов, TCP/IP, возможности и засады ОС, иметь достаточно опыта, приложить много усилий и времени и тогда получится эффективная работа с сокетами.
А если я сделаю поток-на-сокет, и буду отправлять и принимать по одному байту через блокирующие операции, то получится ***ня.
При этом я могу возмущаться "ну у меня же много сокетов и много потоков, почему это работает медленно и не масштабируется! Наверное баг где-то в ОС"

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

R>>>По некоторым авторитетным прогнозам это нас ждёт в очень ближайшем будущем.
R>>>Так что лучше не улыбаться, а учиться создавать масштабируемые системы
R>>>

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

А что "причём"?
Семантики вычислительного ресурса (в данном случае, физического процессора, их множественности) и нитей вычисления определены задолго до появления многопроцессорных машин на столах пользователей. Все программисты писали многонитиевые приложения задолго до использования реальной многозадачности, эмулируя её на однопроцессорной машине в режиме вытесняющей многозадачности (справедливости ради, серверные приложения работали всегда в реальной многопроцессорной среде, на машинах с количеством процессоров больше, чем один).

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

Не бывает! Такого не может быть. Лапшу на уши можно вешать долго и непринуждённо только в окончательно зашоренной атмосфере бытия, но не в IT-отрасли.


R>Есть две совершенно разные вещи, между которыми пропасть. Их надо строго разделять.
R>1. Многопоточность на одном ядре
R>2. Многопоточность на множестве ядер

Нет. Идиомы везде одни и те же: есть один или несколько процессоров, есть одна или несколько нитей -- их нужно раскидать равномерно по ядрам, чтобы ни одно ядро не простаивало, и, в то же время, обеспечить отклик системы на интерактивное взаимодействие. Всё прекрасно известно и прекрасно отработано на высоком уровне с начала 80-х (если не раньше на IBM/360). Задача распределения вычислительных потоков, их динамичская приоритезация и диспетчеризация -- это задача шедулера, оторый -- часть операционной системы!

Если в MS не могут сделать систему, которая эффективно работает на столах пользователей с 4 и более ядрами, то это, очевидно, роблемы Microsoft, а не прикладных программистов.

R>Первое — это просто для удобства программирования и/или для скрытия латентности блокирующих операций. Это то, что умеет значительное кол-во людей. И то, что мы делали десятилетиями.

Определённо да.

R>Второе — производительность и масштабируемость.

Проблемы негров не волнуют белых людей?

R>Первое никак автоматически не перейдёт во второе.

А должно. По идеям, которые нам вдалбливали с детства.

iZEN>>Диспетчеризация потоков выполнения на нескольких физических процессорах -- это прерогатива исключительно операционной системы и/или VM. Так что перекладывать всю ответственность за эффективность функционирования приложения на прикладного программиста -- моветон.

R>Это всё равно, что сказать "TCP/IP стек — прерогатива операционной системы, поэтому можно *любым* образом использовать API сокетов, и ты получишь эффективную программу". Бред! Надо много знать про реализацию сокетов, TCP/IP, возможности и засады ОС, иметь достаточно опыта, приложить много усилий и времени и тогда получится эффективная работа с сокетами.

Это не бред. И TCP/IP здесь совершенно не к месту. Общие задачи планирования вычислений часто решаются на прикладном уровне, но нельзя позволять прикладному уровню отбирать системные ресурсы у уровня аппаратных абстракций, иначе придём к кооперативной многозадачности.

R>А если я сделаю поток-на-сокет, и буду отправлять и принимать по одному байту через блокирующие операции, то получится ***ня.
R>При этом я могу возмущаться "ну у меня же много сокетов и много потоков, почему это работает медленно и не масштабируется! Наверное баг где-то в ОС"

А что, это нельзя сделать на однопроцессорной машине?

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

[]

я почему-то сразу понял о чем они (remark, eao197). Они о том, что interlocked/mutexes могут убить производительность _всей_ системы, а не твоего приложения. Даже не убить, а просто сделать так, что у тебя _не будет_ этих нескольких ядер, а все будет работать, как будто оно у тебя одно. Из-за того, что трэды будут постоянно сбрасывать кеши проца и висеть на объектах синхронизации. При многоядерности вероятность столкновения трэдов гораздо больше. Мы тут не про affinity говорим и не про ручной шедулинг. Это и так понятно, что ОС может лучше разрулить.

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

ZEN>Нет. Идиомы везде одни и те же: есть один или несколько процессоров, есть одна или несколько нитей -- их нужно раскидать равномерно по ядрам, чтобы ни одно ядро не простаивало, и, в то же время, обеспечить отклик системы на интерактивное взаимодействие. Всё прекрасно известно и прекрасно отработано на высоком уровне с начала 80-х (если не раньше на IBM/360).

Только вот более 8-ми ядер в SMP бывает крайне редко. Дальше либо NUMA, либо вообще кластеры. Шедулер конечно что то там под NUMA сможет подогнать, но эффективно задействовать ресурсы системы это вряд ли поможет. Поэтому конкретное приложение должно это самое NUMA учитывать, например при помощи TCP affinity, как это делает сиквел.

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

R>16 аппаратных потоков — полёт нормальный.
R>На днях Intel анонсировала свой новый процессор следующего поколения. Nehalem. 8 ядер. По 2 аппаратных потока на каждом ядре.

Наткнулся сегодня на блог Timothy Mattson, одного из Intel-овских инженеров. Вот его интересные соображения о параллельном программировании и многоядерности:

Parallel Computing: making sequential software rare
Are we insane? 7 simple rules for parallel programming
Parallel programming environments: less is more

Вот, для затравки, цитата из последнего поста:

We need to spend less time creating new languages and more time making the languages we have work. This is why anytime I hear someone talk about their great new language, I pretty much ignore them. Tell me how to make OpenMP work. Tell me how to fix MPI so it runs with equal efficiency on shared memory and distributed memory systems. Help me figure out how to get pthreads and OpenMP components to work together. Help me understand solution frameworks so high level programmers can create the software they need without becoming parallel algorithm experts. But don’t waste my time with new languages. With hundreds of languages and API’s out there, is anyone really dumb enough to think “yet another one” will fix our parallel programming problems?

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

E>Вот, для затравки, цитата из последнего поста:
E>

E>We need to spend less time creating new languages and more time making the languages we have work. This is why anytime I hear someone talk about their great new language, I pretty much ignore them. Tell me how to make OpenMP work. Tell me how to fix MPI so it runs with equal efficiency on shared memory and distributed memory systems. Help me figure out how to get pthreads and OpenMP components to work together. Help me understand solution frameworks so high level programmers can create the software they need without becoming parallel algorithm experts. But don’t waste my time with new languages. With hundreds of languages and API’s out there, is anyone really dumb enough to think “yet another one” will fix our parallel programming problems?

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

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

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

BZ>ассенизатор вычерпивает яму с дерьмом, поднимает ведро наверх, а там его помошник каждый раз хоть понемногу, но прольёт на патрона. тот кряхтит:
BZ>- учись, Петька, а то всю жизнь так в помошниках и проходишь!

Мне больше нравится другая версия этого анекдота:

Из открытого канализационного люка во все стороны разливается дерьмо. Рядом с люком нерешительно мнется молодой сантехник -- не знает, что делать.
Подходит его пожилой напарник, не долго думая ныряет в люк и что-то там ремонтирует. Время от времени он выныривает и молодой подает ему ключи разных размеров.
В конце-концов авария устранена, пожилой отряхивается и с довольным видом говорит:
-- учись, Петька, а то всю жизнь ключи подавать будешь!

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

Будучи еще более тупым чем вы (неспособность изучить Haskell тому доказательство) я, тем не менее, понимаю, что вам вряд ли приходилось сталкиваться со всеми типами задач, требующих распараллеливания. Поэтому и судите вы всего лишь на основании своего ограниченного опыта. И то, что до сих пор вы не сталкивались с проблемами на Haskell-е вовсе не означает, что их вообще нет -- просто вы с ними еще не сталкивались.

M>>ОС — весьма узкое место. Сколько-сколько стоит 32-процессорная винда? ОС ведь такая же программа, как и другие, только побольше. Вон, Intel 16 потоков маскирует под двумя процессорами скорее всего только потому, что современные ОСи до 16 ядер не доросли
ZEN>"Современные ОСи" не входят в TOP500?

Пусть даже и входят, а стоимость?

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

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

ZEN>А что "причём"?


Я высказал свои мысли по этому поводу более подробно здесь

Автор: remark
Дата: 10.10.07

.
Ты с 2000 года с лёгкостью делаешь то, о чём я там говорю? Если да, то я удивляюсь, почему ты ещё что-то пишешь на rsdn, а не спокойно отдыхаешь на своей вилле на канарах.

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

R>Я высказал свои мысли по этому поводу более подробно здесь

Автор: remark
Дата: 10.10.07

.

Я прочитал.
Многие посылки неверные. Скорее всего они основываются на неудачной модели вытесняющей многозадачности Windows, которая не может эффективно распараллелить задачи на 4 и более процессорных ядер. К тому же, слабо учитывает разницу между NUMA- и UMA-архитектурами процессоров (AMD и Intel, соответсвенно).

То, что не умеет Windows, давно и успешно используется в операционных системах Solaris 9 и 10 на процессорах UltraSPARC.

R>Ты с 2000 года с лёгкостью делаешь то, о чём я там говорю? Если да, то я удивляюсь, почему ты ещё что-то пишешь на rsdn, а не спокойно отдыхаешь на своей вилле на канарах.
R>

Может потому, что я не заморачиваюсь и не привязываюсь к Windows и пишу так, как мне удобно, я пребываю всё время в таком жалком состоянии?

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

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

R>>Я высказал свои мысли по этому поводу более подробно здесь

Автор: remark
Дата: 10.10.07

.

ZEN>Я прочитал.
ZEN>Многие посылки неверные. Скорее всего они основываются на неудачной модели вытесняющей многозадачности Windows, которая не может эффективно распараллелить задачи на 4 и более процессорных ядер. К тому же, слабо учитывает разницу между NUMA- и UMA-архитектурами процессоров (AMD и Intel, соответсвенно).

Как она будет это делать, если _сама_ программа не позволяет это делать?

thread1(void*)
{
  ScopedLock lock(Mutex_);
}

thread2(void*)
{
  ScopedLock lock(Mutex_);
}

Что тут делать шедулеру?

ZEN>То, что не умеет Windows, давно и успешно используется в операционных системах Solaris 9 и 10 на процессорах UltraSPARC.

ну-ну

[]

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

ZEN>Я прочитал.
ZEN>Многие посылки неверные. Скорее всего они основываются на неудачной модели вытесняющей многозадачности Windows, которая не может эффективно распараллелить задачи на 4 и более процессорных ядер. К тому же, слабо учитывает разницу между NUMA- и UMA-архитектурами процессоров (AMD и Intel, соответсвенно).

ZEN>То, что не умеет Windows, давно и успешно используется в операционных системах Solaris 9 и 10 на процессорах UltraSPARC.

ZEN>Может потому, что я не заморачиваюсь и не привязываюсь к Windows и пишу так, как мне удобно, я пребываю всё время в таком жалком состоянии?


Да, да, во всей кривизне всегда виновата Windows. Я тоже так считаю, потому что это профессионально.

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

R>16 аппаратных потоков — полёт нормальный.
R>На днях Intel анонсировала свой новый процессор следующего поколения. Nehalem. 8 ядер. По 2 аппаратных потока на каждом ядре. 731 миллион транзисторов. Новый северный мост QuickPath (бывший CSI).

R>Выход запланирован на вторую половину следующего года. Дизайн уже готов.

R>Оригинал здесь. Правда подробностей там не много.

Nehalem Disclosures

In addition to discussing Penryn, Intel also confirmed information that was known about Nehalem, while adding some new details. Nehalem will be released in late 2008 and will use a microarchitecture that is somewhat similar to Merom/Penryn – it will be quad issue/execute/retire. Nehalem will also feature a new instruction set extension, which Intel called “ATA”, on top of SSE4. Unsurprisingly, simultaneous multithreading will make a come back, with each core supporting two logical processors. It will be interesting to see how resources are partitioned, as that was one of the critical problems in the Pentium 4, and later processors have shown much larger gains than the best case 20% that was reported for the P4. Intel describes Nehalem as dynamically managing cores, threads, cache, external interfaces and power – which certainly hints at more intelligent partitioning than the static division of resources in the P4.

There will be product baseds on Nehalem that offer from 1-8 cores, with different cache sizes, memory and interconnect bandwidth, etc. to fulfill different market requirements. The two other expected revelations were that Nehalem will use the Common System Interface to connect elements of a system, and that Nehalem will feature an integrated DDR3 memory controller. One surprise was that Intel’s integrated graphics will be integrated into the same package for some desktop and notebook products. Intel has clearly state that they prefer package integration to chip level integration for a graphics processor. However, Intel might have opted for a discrete northbridge with integrated graphics. Integrating the CPU and GPU on the same package is certainly preferable from an OEM’s point of view; it substantially reduces the chip count, which in turn reduces the complexity of the board. The only down side is that the OEM’s will have a slightly harder time differentiating their products.

Intel has also promised more information in mid-April, when the IDF in Beijing kicks off. However, this is still enough news to digest over the next few weeks.

http://realworldtech.com/page.cfm?NewsID=370&date=03-28-2007#370

R>

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

С>

С>thread1(void*)
С>{
С>  ScopedLock lock(Mutex_);
С>}

С>thread2(void*)
С>{
С>  ScopedLock lock(Mutex_);
С>}

С>

С>Что тут делать шедулеру?

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

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

ZEN>Да не в том дело. Просто не надо ограничивать себя како-то одной операционной системой.

Ага. Но надо ограничивать себя обсуждаемой темой. Эта тема была про процессор.
Лично ты никогда себе Спарк домой не поставишь. Так что кончай очередной гон.

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

R>>А ОС... ну а что ОС? В ней никогда не сделают ничего такого, что магически заставит существующую "одноядерную" программу магически масштабироваться.

M>Сколько-сколько стоит 32-процессорная винда?

Винда лицензируется на камни, а не на ядра. Так что если в одном или двух камнях будет 32 ядра, то стоить она будет как обычная винда.

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

_>>Улыбнуло:
_>>

640 cores should be enough for anybody!

R>По некоторым авторитетным прогнозам это нас ждёт в очень ближайшем будущем.
R>Так что лучше не улыбаться, а учиться создавать масштабируемые системы
R>

Это шутка юмора. Давным давно когда вышел IBM PC с 640 килобайтами памяти Бел Гейтс имен неосторожность ляпнуть фразу "640 kilobytes should be enough for anybody!". Буквально через несколько лет над этим высказыванием смеялись все компьютерщики. Так что данная шутка высмеивает разговоры о на тему "зачем нужно много ядер".

ЗЫ

Говорил ли реально Гейтс данную фразу я не знаю.

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

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

ZEN>>Да не в том дело. Просто не надо ограничивать себя како-то одной операционной системой.
VD>Ага. Но надо ограничивать себя обсуждаемой темой. Эта тема была про процессор.

Согласен.
И как же Windows решает проблемы диспетчерезиции процессов на Nehalem?
http://citcity.ru/18760/

Сотрудники Anandtech в ходе тестирования использовали образец чипа Nehalem с частотой 2,66 ГГц, произведенный по 45-нанометрой технологии и снабженный 8 Мб кэш-памяти третьего уровня. Процессор был установлен в компьютер на базе операционной системы Microsoft Windows Vista Ultimate, оборудованный 2 Гб оперативной памяти.

Согласно результатам, полученным специалистами Anandtech, процессоры Nehalem, в зависимости от типа выполняемой задачи, по производительности на 20-50% опережают современные процессоры Penryn с такой же тактовой частотой. Так, например, в приложении 3dsmax 9 чип Intel Nehalem обгоняет процессор Core 2 Quad Q9450 с частотой 2,66 ГГц на 40%, а в программе Cinebench — на 20%. При этом Nehalem потребляет только на 10% больше энергии по сравнению с чипами Penryn.

Пока никак? Масштабируемость никакая: 40% — это ничто (нормально будет: 100..300% в зависимости от количества ядер).

Вот то-то же...

VD>Лично ты никогда себе Спарк домой не поставишь. Так что кончай очередной гон.

Знаю про списанные, но ещё живые СПАРКи, которые находятся у некоторых товарищей дома.
Чисто по приколу могу себе позволить Sony PlayStation3 с Yellow Dog Linux на борту и процессором Cell.
Но это ничего не значит — могу я поставить себе SPARC домой или не могу. Вопрос в другом: А надо ли?