Fortress 1.0

>Меня в детстве учили: если дорого хранить, то иногда дешевле пересчитать ;)

Ну везде есть разумные рамки ;) Не всегда же пересчитать дешевле.

>>Меня в детстве учили: если дорого хранить, то иногда дешевле пересчитать ;)

>Ну везде есть разумные рамки ;) Не всегда же пересчитать дешевле.

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

Кстати, говоря про IO, мне всегда приходит на ум фраза, которую сказал кто-то из великих и часто приписываемая то Кнуту, то Дейкстре:

"Суперкомпьютер - это прибор, переводящий CPU-intensive task to IO-intensive task". Продолжая мысль - "чем больше решена проблема CPU, тем хуже будет с проблемой IO" ;)

google хорошая вещь.

Специально нашёл публичную ganglia с примеров в walltime в 20 c хвостиком дней

http://pizarro.acrl.uh.edu/ganglia/addons/job_monarch/?c=Eldorado&view=ov...

Хотелось бы посмотреть на тов. dhomouz-а если оно навернётся через 10 дней ;)

> Хотелось бы посмотреть на тов. dhomouz-а если оно навернётся через 10 дней ;)Хотелось бы посмотреть на тов. dhomouz-а если оно навернётся через 10 дней ;)

16 CPU? Даже если каждый узел 16G, полный dump можно сделать за 10 min => вопрос об IO вообще не стоит. Если предположить, что 1 Itanium в 12 раз быстрее нашего PPC450 (что очень не так), задача товарища dhomouz-a будет (при идельном масштабировании, что тоже не так) на 32K CPUs считаться 3.6s. Ладно, молчу - молчу ;)

p.s. По задаче и архитектура - не нужно долгие задачи на 8 узлах считать.

>на 32K CPUs считаться 3.6s

Это o-o-o-чень сильно от задачи зависит ;)

>p.s. По задаче и архитектура - не нужно долгие задачи на 8 узлах считать.

А 64к узлов есть далеко не у всех а жить как то надо ;)

>>на 32K CPUs считаться 3.6s

> Это o-o-o-чень сильно от задачи зависит ;)

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

> А 64к узлов есть далеко не у всех а жить как то надо ;)

Ну я же сказал - молчу ;)

ладно, а вот если стёб в сторону - у них четверть кластера DOWN, у нас системщики уже бутылки бы собирали при таком downtime.

> Удобство же вообще должно быть на пятнадцатом месте, когда речь идёт о Fortran.

Никак не могу согласиться. Человеческий ум ограничен -- если помимо предметной области еще и бороться с языком -- это сверхтребование. Относительно простой синтаксис Фортрана дает возможность написать простой компилятор, что в 70-80 г. было (наверное) важным преимуществом. Сейчас времена компиляции -- это, наверное, последнее, что оптимизуют в программах. А вот статическое размещение структур данных в памяти и недостаточная гибкость в организации нужных по смыслу задачи стурктур серьезно осложняет программирование, уводя его на "низкий" уровень.

> У нас в своё время говорили "хороший программист на Fortran пишит на Fortran на любом языке."

Это точно! :)))

> простой синтаксис Фортрана дает возможность написать простой компилятор, что в 70-80 г. было (наверное) важным преимуществом.

8) Фортран-компиляторы, наверное, были в то время самыми сложными (а может, и остались :D).

>у них четверть кластера DOWN, у нас системщики уже бутылки бы собирали при таком downtime.

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

to annoynimous and tailgunner

>> простой синтаксис Фортрана дает возможность написать простой компилятор, что в 70-80 г. было (наверное) важным преимуществом.

>8) Фортран-компиляторы, наверное, были в то время самыми сложными (а может, и остались :D).

Вопрос не в том, чтобы написать компилятор, и уж тем более не в том, чтобы написать быстрый копмилятор. Вопрос в том, чтобы написать *оптимизирующий* компилятор, а вот это очень непросто.

Кстати, дабы не было вопросов, оптимизирующий - это не значит по плохому отфонарному коду выдать быстрый объектный код. Это по очень хорошему, но не ассемблерному, коду выдать объект близкий к качеству ассемблера с 80% производительности от пика.

> Никак не могу согласиться. Человеческий ум ограничен -- если помимо предметной области еще и бороться с языком -- это сверхтребование.

Значит Вам не следует выбирать Fortran для своих задач. Язык нельзя выучить, с ним не нужно бороться - его нужно чувствовать, а приходит это с опытом. Когда и если Вам придётся "выжимать" 1 процент от времени исполнения программы ценой переписывания 50,000 строк C++ кода, и Вам очень не захочется это делать на ассемблере, Вы вспомните про Fortran.

> Я кстати сам удивился когда погуглил по ганглиям в инете насколько слабо загружены кластеры, причём многие явно террафлопсофого класса.

Может DOWN означaет reserved for special use, а на самом деле эти ноды трудятся в поте лица :)

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

Мы в своих расчётах полагаем, что техника класса 50TF устаревает за 3 года. Вообще, если подумать - это фантастика!

> опрос не в том, чтобы написать компилятор, и уж тем более не в том, чтобы написать быстрый копмилятор. Вопрос в том, чтобы написать *оптимизирующий* компилятор, а вот это очень непросто.

Ну о том и речь. Фортрановские компиляторы изобрели большую часть оптимизаций вообще, и, наверное, все оптимизации, связанные с распараллеливанием.

> наверное, все оптимизации, связанные с распараллеливанием

Самая большая проблема, с которой я сталкиваюсь постоянно (Fortran позволяет её решать, а C/C++ постоянно скрывают и тем самым ещё больше уходшают ситуацию) выборка из памяти. Именно поэтому я и написал вверху - common, как гарантированно неразрывный блок памяти - это очень хорошо. А автоматическое распараллеливание - это академические развлечения, кстати sS очень интересную ссылку вверху привёл, где в точности подтверждается этот тезис.

> автоматическое распараллеливание - это академические развлечения, кстати sS очень интересную ссылку вверху привёл

Про HPF? Это было гораздо позже 70-80-х, уже после заката суперов, на которых рулили параллельные (векторные) оптимизации.

Цитаты со ссылки: "векторизация была исключительно успешной технологией", "коммерческие компиляторы, штатным образом автоматически параллелизующие программы для небольшого числа процессоров" :) Так что насчет игрушек - это сильно сказано, хотя вам виднее...

Упс. Рахождение в терминологии.

Под автоматическим распараллеливанием я имел в виду только крупноблочное распараллеливание. Векторизация, как мелкозернистое распараллеливание --генерация специализированных команд по явному векторному коду -- очень хорошая и успешная метода, но она никак не помогает проблеме выборки из памяти, а наоборот создаёт bottleneck и/или в cache/на шине. К тому же векторизовать всё-равно приходится вручную. А вот "поиск образцов векторного кода по скалярному" - по мне так баловство. Конечно, может и ошибаюсь...

>Может DOWN означaет reserved for special use, а на самом деле эти ноды трудятся в поте лица :)

Возможно, но в PBS они видны как down что иногда мешает оптимально загружать кластер.

> Под автоматическим распараллеливанием я имел в виду только крупноблочное распараллеливание.

В стиле MPI? Так это даже у людей не получается :)

>как гарантированно неразрывный блок памяти - это очень хорошо.

Это хорошо для больших shared кешей но абсолютно противопоказано для NUMA.

Именно по этой причине программа, оптимизированная под последние Xeon-ы (имеется ввиду оптимизация доступа к памяти а не специфичный набор векторных инструкций) сольёт на NUMA архитектуре (Opteron-ы) и наоборот. Кстати последние Оптероны (Барселона) это гибрид первого и второго сразу, и ходы по оптимизации там могуть быть нетривиальны и весьма эффективны.

>В стиле MPI? Так это даже у людей не получается :)

Ну не всё так плохо. ;)

>> Под автоматическим распараллеливанием я имел в виду только крупноблочное распараллеливание.

>В стиле MPI? Так это даже у людей не получается :)

А разве не это заявляется? На вход - обычная Fortan программа, на выход Fortran c явными MPI вызовами. Самое оно ;)

>Мы в своих расчётах полагаем, что техника класса 50TF устаревает за 3 года. Вообще, если подумать - это фантастика!

Наверное даже быстрее ... еще год-два назад рабоче-крестьянский (если не брать эксклюзив) террафлопс помещался в 42U-стойку, сейчас это одно шасси 6U блейдов.

>>как гарантированно неразрывный блок памяти - это очень хорошо.

>Это хорошо для больших shared кешей но абсолютно противопоказано для NUMA.

Почему? Размером common блока, как и "местом его расположения в памяти" тоже можно манипулировать. А вот то что

> программа, оптимизированная под последние Xeon-ы ... сольёт на NUMA архитектуре (Opteron-ы)

так это примерно то же самое, как программу для CM-2 запускать на Intel Paragon или Sequent и удивляться что "всё навернулось" ;) Нет?

> Кстати последние Оптероны (Барселона) это гибрид первого и второго сразу, и ходы по оптимизации там могуть быть нетривиальны и весьма эффективны.

И абсолютно непереносимы. А кстати, чем это отличается от обычного MPI-программирования?

>И абсолютно непереносимы.

До некоторой степени. В данном случае нужно что то типа автоматического определения топологии что реализуется один раз и на многие случаи жизни. В конце-концов слегка помочь руками даже не при сборке а прямо в исходных данных.

>А кстати, чем это отличается от обычного MPI-программирования?

Мало чем. Кстати на таких "гибридных" архитектурах народ любит мешать OpenMP и MPI. Правда в этом случае боттлнеки могут возникать в весьма неожиданных местах.

PS: Я кстати не сторонник настолько "гибридных" парадигм. Уж если MPI то MPI.

>Размером common блока, как и "местом его расположения в памяти" тоже можно манипулировать.

Мы видимо имеем ввиду всё же блоки разного размера ;)

Если размер такого блока - страница памяти ну или даже он соизмерим с размером кеша то да, а если блок имеет размеры от сотен мегов до гигов ?

> Если размер такого блока - страница памяти ну или даже он соизмерим с размером кеша то да

Точнее - кратный размеру L3 cache и структурированный согласно длине строки. Но это в общем случае, а вообще уже зависит от задачи.

> а если блок имеет размеры от сотен мегов до гигов ?

Осталось ещё добавить "чтобы было интереснее решать задачу" ;)

Значит пора пересматривать распределение данных: при неоднородном доступе к разделяемой памяти я бы определённо уменьшал блоки. Хотя...

>а вот VB.NET - вполне себе современный функциональный язык программирования (вижу летящие помидоры, ныкаюсь в бункер).

Забетонируйте его там.

>Но в байт-код, который выполняется в _интерпретаторе_ байт-кода (ака java-машина, jvm)!

У тебя анабиозный саркофаг сбоит.

Кто первым выпустик клавиатуру для фортреса.

>>А впрочем... ссылку на оптимизацию формул генетическими алгоритмами?

>Трекин А.Г. Построение расписаний при совместном проектировании аппаратных и программных средств неоднородных ВС с помощью генетических алгоритмов

Правильное распределение по потокам - это хорошо. Но не всегда возможно. Я говорил про оптимизацию в рамках одного потока.

Хорошо, пусть не генетические алгоритмы.

> Язык нельзя выучить, с ним не нужно бороться - его нужно чувствовать, а приходит это с опытом.

Извините, все это пустые декларации. Замените в этой фразе "язык" на любое другое сужествительное -- "матан", "теормех", "квантмех" -- и она останется столь же содержательной. Я к чему это все? А к тому, что многие из недостатков Фортрана являются "legacy", т.е. устаревшими, но которые поддерживаются и наследуются в угоду консервативной части пользователей этого языка и огромному объему уже написанного кода. Кроме того, думаю, что многие нынешние пользователи Фортрана пришли в него тем же путем, что и я сам: просто в наследство мне досталось много кода, написанного на этом языке, и легче оказалось выучить язык, чем переписывать этот код.

> Когда и если Вам придётся "выжимать" 1 процент от времени исполнения

Никогда такой задачи не возникало и, думаю, не возникнет: я ж не real-time управление ядерным реактором пишу. Подождать еще 1% от _общего_ времени -- сущие пустяки. Чаще всего возникает вопрос об ускорении в разы, а здесь требуется напряжение всех интеллектуальных сил, и отсутствие поддержки со стороны языка (в перевую очередь, его выразительности, дабы "ухватывать" взглядом как можно больший объем в целом) может неприятно сказаться.

И от общих слов к частностям: помню, мне понадобилось изменить определение одного common-блока в своей программе: так я задолбался вручную по нескольким файлам (порядка 8) выискивать его объявление, чтобы поменять. Да, можно пользоваться директивой include, однако, как мне известно, она не входит в стандарт, по крайней мере 77 Фортрана, который мы долгое время использовали в виде g77. А common-блоки единственный способ хоть как-то структурировать глобальное пространство имен и избежать простыни аргументов, передаваемых в функцию (в противном случае, >10 аргументов получить вообще не проблема).

>> а вот VB.NET - вполне себе современный функциональный язык программирования (вижу летящие помидоры, ныкаюсь в бункер).

> Забетонируйте его там.

Про VB он большей частью прав ;)

>Значит пора пересматривать распределение данных: при неоднородном доступе к разделяемой памяти я бы определённо уменьшал блоки. Хотя...

Дык эта. На halo exchange потеряете еще больше...

>просто в наследство мне досталось много кода, написанного на этом языке, и легче оказалось выучить язык, чем переписывать этот код.

У меня была аналогичная ситуация но было принято волевое решение и весь отдел целиком слез с фортрана переписав кучу кода сначала на це а потом и частично на плюсы. Правда переползали довольно долго.

> Господин ламер, байткоды JVM КОМПИЛИРУЮТСЯ в нейтив JIT-компилятором. Съешьте, пожалуйста, ещё этих мягких французских булочек с йадом.

И где тогда хвалёная платформонезависимость явы??? Раскройте мне глаза.

> > А где же здесь научная новизна?

> PS: Кандитатский дисер это _квалификационная_ работа (в отличае от докторской)

Несмотря на это, пункт научная новизна в кандидатской должен быть и вопрос это первостепенной важности.

>Чаще всего возникает вопрос об ускорении в разы, а здесь требуется напряжение всех интеллектуальных сил, и отсутствие поддержки со стороны языка (в перевую очередь, его выразительности, дабы "ухватывать" взглядом как можно больший объем в целом) может неприятно сказаться.

Тут уже приводили способ как это можно сделать "в разы" :)

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

>Несмотря на это, пункт научная новизна в кандидатской должен быть и вопрос это первостепенной важности.

Эта новизна зачастую сродни изобретению велосипеда ;)

>И где тогда хвалёная платформонезависимость явы??? Раскройте мне глаза.

Она настолько же платформонезависима как и gcc.

> Несмотря на это, пункт научная новизна в кандидатской должен быть и вопрос это первостепенной важности.

> Эта новизна зачастую сродни изобретению велосипеда ;)

Ну, это и в докторских бывает.

> Тут уже приводили способ как это можно сделать "в разы" :)

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

Я тупой, до меня долго доходит. Имеется в виду использование параллельных вычислений?

> И где тогда хвалёная платформонезависимость явы??? Раскройте мне глаза.

Господин ламер, на каждой платформе есть свой компилятор JVM->native. Стукните себя вилкой в глаз, пожалуйста.

>Имеется в виду использование параллельных вычислений?

Да.

> Забетонируйте его там.

А вот и убейся:

http://community.livejournal.com/ru_lambda/80800.html

>А вот и убейся:
>http://community.livejournal.com/ru_lambda/80800.html

fa = lambda x: 1 if x<=1 else x * fa(x - 1)
print fa(10)

Сам убейся, элементы функциолнальщины у нас всюду и давно.

Язык, на котором можно написать Y-комбинатор - это функциональный язык, по определению. Так что раз уж на VB.NET его написать можно, VB.NET - функциональный язык. Это не "элементы", это полноценная функциональщина.

Кстати, насколько я понимаю, на одних только лямбдах в пистоне то же самое не сделать, придётся именованные определения вставлять. Так что VB.NET лучше как минимум пистона.

> Кстати, насколько я понимаю, на одних только лямбдах в пистоне то же самое не сделать, придётся именованные определения вставлять.

Посыпаю голову пеплом, слажал, да, с комбинаторами все плохо. Пока признаю VB.NET более функциональным.