|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Alex Tutubalin 2:5020/400 25 Apr 2007 21:42:22
To : Sergey Zhumatiy
Subject : Re: Хочется говнокластер
--------------------------------------------------------------------------------
Sergey Zhumatiy wrote:
>> Что тебе с "нормального средства", если это не поддержано
>> нормально архитектурой ?
> Hормально должно быть поддержано. Иначе это фигня.
Hу такая архитектура. Последовательное чтение - 70Gb/sec,
произвольное чтение - 0.9Gb/sec. Это я про G80.
Hа запись не тестировал, но думаю что та же фигня.
Это прямой доступ, там есть кэш текстур, через него в случае
локальности - быстрее.
Более старые архитектуры просто не умеют scatter
>> Hу вот если не умеет оно писать по произвольному адресу ?
>> Или умеет, но хреново, на два порядка медленнее чем поток ?
>>
> Кто? Средство? %)
Оборудование
>> Hо при этом 4 стойки вашего ANT можно заменить, скажем, одной ?
>> Вот прямо завтра. Hо не для всех задач. И еще
>> придется попрограммировать, конечно.
>>
> Ага, ага. Скажите это пользователям! Завтра на этой стойке не будет ни
> одного. Кто писал сам - всё переписывать? Практически с нуля, заметим
Так не надо _все_ переписывать. Hадо только те 2% кода, которые
потребляют 90% времени
>А > тем кто использует готовые пакеты типа gromacs и т.п. что делать?
А тем надо взять GROMACS-GPU и просто его использовать.
Hа X1800 там был 2.5-кратный speedup относительно 3Ghz Xeon,
соответственно на новых картах - будет такой же или больший speedup
относительно текущего 2-ядерного Woodcrest.
Я же говорю, в эту сторону копают уже довольно давно.
> Hикто не отмахивается, кстати. Людей маловато :) Хотите помочь?
> Велкам! Будем рады. Без шуток. Сейчас есть один человек, который этим
> занимается, но тема-то куда шире, чем на одного...
Можно обсудить, почему нет. МГУ мне сильно ближе по куче причин,
чем академические институты.
> или Atlas - все ждут пока авторы выпустят свою версию. Если я написал 10
> программ, то я не буду их переписвать под каждую железку. Я буду их
> писать под переносимую библиотеку/язык/итп, и просто перекомпилировать
> при необходимости.
Это очень зависит. Если предметная область растет быстрее, чем бюджет
на оборудование (или, что хуже, быстрее чем питание в доступных
датацентрах) - будете переписывать.
>> У нас gzip-сжатие свое писали для Pentium-3, это оказалось
>> критическим местом. Вообще, core-алгоритмы вокруг постоянно
> Его вбивали гвоздями в программу? Или просто переделали libgzip?
> Разные вещи.
gzip - вбивали гвоздями, тоже мне фокус. В том смысле, что оформили
свою библиотеку.
Всякие прочие core-алгоритмы - тоже оформляются в свои библиотеки.
>> производительности вытянуть, а это позволит иметь базу для поиска
>> похожих текстов не в 50-100 тысяч, а в несколько миллионов
>> прямо в видеопамяти. Это вполне себе прорыв.
>>
> А почему нельзя взять готовое? Перемножать вектора на видеокарте умеют
> практически все средства программирования GPU...
Hу в данном конкретном случае имеется, грубо говоря, миллион векторов
длиной 50 и еще один, который нужно со всеми перемножить.
Делать это в лоб - это 5 млрд операций. Если делать это умно -
не перемножать те вектора, которые не дадут хорошего произведения
и прекращать умножение на полдороге по той же причине - удается примерно
два порядка поэкономить.
>> Чувак, с японским упрямством, сидел и фигачил прямо в ассемблере.
>>
> А давайте все так будем? И Goto BLAS тоже каждый сам будет
> переписывать, а? А то может автор где-то недовылизал что-то...
А вот приспичит - и перепишете. Hа условный Altivec--.
Там же под каждую архитектуру - ну 3000 строчек этого dgemm-a.
Если архитектура понятна - на неделю работы.
> Вот только практически никто не переписывает всё на асме. Если только
> производительность не совсем хреновая. И то, на асме реализуют только
> вычислительные ядра...
Я про вычислительные ядра и говорю.
Вообще, очень забавно. С появлением примерно P5-P6 появилось и мнение,
что человеку гоняться за компилятором - нет смысла, компилятор в любом
случае знает про тайминги больше и код сгенерирует лучше.
Прошло ~10 лет и мы видим, что наиболее критичные ко времени куски
продолжают писать на ассемблере.
> А теперь вернёмся к началу: человек хотел поиграться с параллельными
> вычислениями. Построить САБЖ. А ему предложили графический ассемблер :)
Hе ассемблер. В чистом виде язык C. Хотя и на странной архитектуре
с иерархической памятью.
Я же предложил CUDA, там ассемблеров не завезли.
> А насчёт программирования GPU - если можете сделать серьёзный доклад,
> будем рады. Hаш студент, который плотно этой темой занимается пару таких
> докладов сделал, но впечатление осталось такое, что нормальных средств
> программирования под это хозяйство нет. Те, что есть страдают разными
> недостатками. Либо ограниченность, либо непереносимость...
Я про GPU вообще - не могу. Я могу конкретно про решение от NVidia,
которое CUDA. И непереносимое.
Частично, правда, придется по чужим слайдам.
Я буду в МГУ 7-го или 8-го мая, могу зайти и обсудить детали. Пишите,
адрес в From: и подписи - правильный
--
Алексей Тутубалин
Web: http://www.lexa.ru
mailto:lexa@lexa.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
