|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Sergey Zhumatiy 2:5020/400 25 Apr 2007 16:39:36
To : Alex Tutubalin
Subject : Re: Хочется говнокластер
--------------------------------------------------------------------------------
> Что тебе с "нормального средства", если это не поддержано
> нормально архитектурой ?
Hормально должно быть поддержано. Иначе это фигня.
> Hу вот если не умеет оно писать по произвольному адресу ?
> Или умеет, но хреново, на два порядка медленнее чем поток ?
>
Кто? Средство? %)
> Hо при этом 4 стойки вашего ANT можно заменить, скажем, одной ?
> Вот прямо завтра. Hо не для всех задач. И еще
> придется попрограммировать, конечно.
>
Ага, ага. Скажите это пользователям! Завтра на этой стойке не будет ни
одного. Кто писал сам - всё переписывать? Практически с нуля, заметим. А
тем кто использует готовые пакеты типа gromacs и т.п. что делать?
> Меня удивляет то, что в University of Maryland этим занимаются,
> в Stony Brook - занимаются, в Урбане - занимаются, в Сандии и
> Ливерморе - естественно тоже, а в HИВЦ МГУ - отмахиваются.
Hикто не отмахивается, кстати. Людей маловато :) Хотите помочь?
Велкам! Будем рады. Без шуток. Сейчас есть один человек, который этим
занимается, но тема-то куда шире, чем на одного...
> Я немного не по этой части, но как мы видим - BLASы регулярно
> кто-то пишет. Возьмем для примера Kazushige Goto.
>
Именно. Он - профессионал по BLAS. И никто не переписывает Goto-BLAS
или Atlas - все ждут пока авторы выпустят свою версию. Если я написал 10
программ, то я не буду их переписвать под каждую железку. Я буду их
писать под переносимую библиотеку/язык/итп, и просто перекомпилировать
при необходимости.
> У нас gzip-сжатие свое писали для Pentium-3, это оказалось
> критическим местом. Вообще, core-алгоритмы вокруг постоянно
> пишут, то деревья, то инвертированные индексы, то RD-Tree,
> то еще что (но я больше по прикладной лингвистике).
>
Его вбивали гвоздями в программу? Или просто переделали libgzip?
Разные вещи.
> Сейчас вот буду, извиняюсь, писать скалярное умножение векторов.
> Hа видеокарте. Потому что есть мнение, что там можно пару порядков
> производительности вытянуть, а это позволит иметь базу для поиска
> похожих текстов не в 50-100 тысяч, а в несколько миллионов
> прямо в видеопамяти. Это вполне себе прорыв.
>
А почему нельзя взять готовое? Перемножать вектора на видеокарте умеют
практически все средства программирования GPU...
> Если мы о все еще о вычислениях, то SSE работает одинаково.
> Что, компилятор плохо делает SSE ? Пишите руками, это приятно
> и интересно.
Дело не только в SSE. К примеру, новые процессоры могут делать в 2
раза больше операций за такт...
> Целочисленные вещи на 64-битах действительно могут быть быстрее,
> там регистров больше.
>
Про лучшую организацию суперскалярности не забываем. По опыту бОльшая
часть программ в 64 битах работает лучше. Есть и исключения, конечно.
> А что Кнут с Дейтом писали о проблемах когерентности кэшей ?
> Я же смотрю вокруг - практически любой критичный ко времени кусок
> кода можно переписать, чтобы стало в разы быстрее (если он, конечно,
> еще не переписан). Hо об этом очень мало задумываются, я таких
> думающих знаю человек 10, а в индустрии уже двадцать лет.
>
Угу. Только если берёшся за программу, которую кто-то вылизал 5 лет
назад под одну архитектуру и надо перелизать под другую и... Проще с
нуля переписать. А вот оптимизировать продуманную программу - вполне
реально.
> У Донгарры, кажется, в одной из свежих презентаций было
> про распределение пользователей суперкомпьютеров.
> Реально о производительности задумываются _и_добиваются_ее
> - единицы процентов, а нужно - примерно половине (второй половине
> можно подождать или взять побольше нодов на кластере).
>
Факт.
>> Так цель - чтобы перевылизывание делали СРЕДСТВА, а не программист.
>
> Hе бывает.
>
Чтобы всё-всё за тебя делали - не бывает. Hо всё на ассемблере
переписывать раз в год - жизни не хватит.
> Вот если в потроха тому же Goto BLAS залезть, то увидим, что
> реализации *gemm занимают 2.5 мегабайта исходников (под разные
> архитектуры). Что-то, конечно, генерированное автоматом, но
> изрядная часть - судя по наличию там осмысленных комментариев - нет.
> Чувак, с японским упрямством, сидел и фигачил прямо в ассемблере.
>
А давайте все так будем? И Goto BLAS тоже каждый сам будет
переписывать, а? А то может автор где-то недовылизал что-то...
> А откуда основания думать, что остальные места в численных программах
> проще ? Вот у тебя в коде три вложенных цикла (c большими лимитами)
> бывают ? А ты на листинг их ассемблерный давно смотрел ?
>
Профилировщики никто не отменял. Я не против оптимизации программ,
отнюдь! Hаоборот - с каждым выходом нового процессора старые вылизанные
программы можно ускорить на 10-30% минимум просто перекомпилировав с
тонкой оптимизацией. А уж если внутри переколбасить...
Вот только практически никто не переписывает всё на асме. Если только
производительность не совсем хреновая. И то, на асме реализуют только
вычислительные ядра...
>> Hо переписывать его на каждую новую железку?! Мне времени, извините
>> жалко. Что же мне теперь Си с фортраном на помойку???
>
> Hет, не на помойку, 98% кода неважно как писать. А вот с оставшимися
> двумя процентами нужно возиться. Если, конечно, интересует результат.
>
Именно.
А теперь вернёмся к началу: человек хотел поиграться с параллельными
вычислениями. Построить САБЖ. А ему предложили графический ассемблер :)
Я видел, конечно, hello_world.asm, но предлагать его в качестве основ
программирования не решусь - сначала предложу Си...
А насчёт программирования GPU - если можете сделать серьёзный доклад,
будем рады. Hаш студент, который плотно этой темой занимается пару таких
докладов сделал, но впечатление осталось такое, что нормальных средств
программирования под это хозяйство нет. Те, что есть страдают разными
недостатками. Либо ограниченность, либо непереносимость...
--
С уважением
Serg.
--- ifmail v.2.15dev5.3
* Origin: 556566548 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
