Каморка

OMFG, как хорошо что придумали конструторы...
Инаврианты всякие...

В продолжение разговора об инвариантах:
Месяца два назад после 10-ти лет работы умер Mars Global Surveyor.
А вчера вот собщили:
"We think that the failure was due to a software load we sent up in June of last year. This software tried to synch up two flight processors. Two addresses were incorrect - two memory addresses were over written. As the geometry evolved, we drove the [solar] arrays against a hard stop and the spacecraft went into safe mode. The radiator for the battery pointed at the sun, the temperature went up, and battery failed. But this should be treated as preliminary."
http://www.spaceref.com/news/viewnews.html?id=1185

Давно пора им на Java переходить ну и что, что памяти надо в 5 раз больше, а CPU 1.5-2 раза мощнее, зато можно прочитать exception stack trace если что...

а АДА на что тогда спрашивается ?

ajkj3em писал(а):а АДА на что тогда спрашивается ?

АДА, как я понимаю умерла уже давно, не сложилось...
Ничего,вот сделают какой-нибудь 128-ми ядерный кристалл тогда никуда от Jav-ы(или чего нибудь подобного) не денуться.

Ветку еще не читал, поэтому возможно повторю кого-то.
Второй кошернее по двум причинам:
1. Меньше констрейнов на переменные, а потому более простые проверки на валидность.
2. Первый неявно дает понять, что доступ будет осуществляться пойнерами, а не индексами. Доступ пойнтерами хуже доступа индексами (кроме локальных случаев оптимизированного кода) тем, что индекс може без изменений быть передан за границы процесса, а пойнтер надо преобразовывать. Аналогично, кстати и с длиной.

Сегодня, кстати, любопытную лекцию посетил про Designing For Concurency. Все больше и больше народу утверждает, что переключение контекстов нужно только для систем где есть недостаток процессоров. А по сути от него только вред.

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

Собственно, Sony это и имела в виду, когда делала PS3 - переключение контекстов не только замедляет выполнение, но и усложняет программирование. Хотя, на мой взгляд, они выступили черезчур радикально - совместный доступ к памяти можно было и оставить.

Старина Зотин писал(а):Все больше и больше народу утверждает, что переключение контекстов нужно только для систем где есть недостаток процессоров. А по сути от него только вред.

Согласен на 95%, просто бывают такие задачки, когда большинство потоков сидят на IO-waits. Конечно можно весь IO сделать асинхронным, но тогда запаришься его программировать.
добавление: я так понимаю что я описал случай "систем где есть недостаток процессоров"

Старина Зотин писал(а): У нас большинство команд перешло на дизайн при котором сразу запускается ровно столько потоков, сколько есть ядер, а потом спец scheduller распределяет между ними задачи. Настолько проще синхронизироваться, по сравнению с обычной многопоточностью - просто небо и земля.

А вот тут поподробнее можно?

Старина Зотин писал(а): Собственно, Sony это и имела в виду, когда делала PS3 - переключение контекстов не только замедляет выполнение, но и усложняет программирование. Хотя, на мой взгляд, они выступили черезчур радикально - совместный доступ к памяти можно было и оставить.

Shared memory это зло! IMHO...

Marmot писал(а):Конечно можно весь IO сделать асинхронным, но тогда запаришься его программировать.

фиии

ajkj3em писал(а):

Marmot писал(а):Конечно можно весь IO сделать асинхронным, но тогда запаришься его программировать.

фиии

Ты, эта, как-нибудь попробуй к какой-нибудь базе данных присоединись асинхронно... и расскажи нам потом...

Marmot писал(а):А вот тут поподробнее можно?

Ну примерно так.
Есть такое понятие как Job. Это некоторый кусок кода и некоторые данные. Jobs образуют динамический граф зависимостей.
Например, стартовый пойнт программы это job A, который для своих целей запускает jobs B и C. Причем В готовит данные для C, а потому C объявляется зависимым от B. То есть, система не начнет его выполнять, пока B не завершен. При этом A может либо переключиться на ожидание С (плохая идея, поскольку держит вычислительный ресурс), либо для продолжения своих задач создаст job D, который сделает зависимым от C, что гарантирует его вызов только после завершения всех вычислений, то есть, когда данные уже готовы.

Немного другая идеология программирования, но если привыкнуть, то все очень просто и очень эффективно. Никакой явной синхронизации не нужно - все синхронизировано системой. Дедлок тоже не грозит - он разрешается на этапе редактирования графа. Если job пошел в работу - никто его не прервет и не испоганит ему cache - можно спокойно оптимизироваться префетчами (это в идеальном мире будущего - сейчас на симметричных системах этого нельзя гарантировать - все равно ведь все управляется системным thread scheduller).

При этом граф можно редактировать на лету. Например, jobs B1, B2, B3... BN все зависят от job A. A готовит данные для B1 и перед тем как переключаться на B2 удаляет зависимость B1 от A. Теперь B1 свободен и может начинать выполнение.

весьма не дурно

ps пищи есчо :)

Старина Зотин писал(а):

Marmot писал(а):А вот тут поподробнее можно?

Ну примерно так.
...

Ага понял, прочитал и вспомнил, что я уже где-то видел похожие идеи: http://blogs.sun.com/dave/entry/parallelism_manifesto

aissp писал(а):В первом случае максимальный размер блока будет только 2 гига когда во втором ажно 4

Ну это зависит от sizeof(char *) и sizeof(size_t). Ни то ни другое в данной задаче не описано.

-Maxim

Старина Зотин писал(а):Собственно, Sony это и имела в виду, когда делала PS3 - переключение контекстов не только замедляет выполнение, но и усложняет программирование. Хотя, на мой взгляд, они выступили черезчур радикально - совместный доступ к памяти можно было и оставить.

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

Не знаю кто там что говорит а John Carmack весьма нелестно отзывается на тему писания софта под PS3.

http://www.gamasutra.com/php-bin/news_i ... tory=12351

Так что не исключено что весь hype по поводу cell закончится пшиком.

-Maxim

Marmot писал(а):

ajkj3em писал(а):

Marmot писал(а):Конечно можно весь IO сделать асинхронным, но тогда запаришься его программировать.

фиии

Ты, эта, как-нибудь попробуй к какой-нибудь базе данных присоединись асинхронно... и расскажи нам потом...

funny enough ровно (!) втим сеичас и занимаюсь - из под линукса к MSSQL через чистый TDS ... конечно не "hello world", но и не rocket science. все бегает ассинхронно .. чай не джава какая-нибудь :)

sobomax писал(а):Ну не знаю, не знаю. У PS3 все-таки один нормальный процессор и много недо-процессоров, нормальные потоки на них не запустиш так что переключение контекстов никуда не денется.

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

А потом когда сделали (да еще и задизайнили так, чтобы это на любой платформе работало - и xbox и pc тоже), стали понимать, что они удобнее, на самом деле, чем эти системы с переключением контекста. И эффективнее.

sobomax писал(а):Не знаю кто там что говорит а John Carmack весьма нелестно отзывается на тему писания софта под PS3.

http://www.gamasutra.com/php-bin/news_i ... tory=12351

Это он еще скромничает.
Что может девелопер сказать про систему, к которой дается дебагер, который врет значения переменных. Но мало того, код на SPU он вообще не умеет трейсить, а в стандартной библиотеке на SPU нет функции printf. Как прикажете отлаживать код?

И это когда рядом есть пример xbox2, который включаешь в розетку, устанавливаешь xdk и отлаживайся до умопомрачения прямо из VC. А на любой чих жмешь F1 и получаешь полное описание API с примеравми кода из MSDN.

sobomax писал(а):Так что не исключено что весь hype по поводу cell закончится пшиком.

Возможно, хотя и не думаю. Все производители игр ворчат, но все портируются.

Но смысл истории не в этом. Смысл в том, что такие системы, где строится граф зависимостей задач легче делать, чем то как это сейчас делается с потоками. А при условии наличия десятков/сотен ядер (к чему все идет независимо от ps3), они еще и работают быстрее.
Кроме того, они почти прозрачно поддерживают даже такие экзотические вещи как cell.