Здравствуйте, korzhik, Вы писали: K>только начал знакомиться с Erlang. Сразу возник вопрос: есть ли какие нибудь реализации Erlang способные запускаться на NVidia CUDA ?
Рискую попасть пальцем в небо, но Вы не пробовали собрать эрланг под это платформу? Исходники-то открыты.
Здравствуйте, korzhik, Вы писали:
K>Всем привет
K>только начал знакомиться с Erlang. Сразу возник вопрос: есть ли какие нибудь реализации Erlang способные запускаться на NVidia CUDA ?
Здравствуйте, korzhik, Вы писали:
K>только начал знакомиться с Erlang. Сразу возник вопрос: есть ли какие нибудь реализации Erlang способные запускаться на NVidia CUDA ?
рискуя отгадать, предположу, что ты незнаком со спецификацией этих процессоров. именно у таких людей возникаюь гениальные идеи о переносе всего вподряд под sse, cuda и порчие ускорители интернета
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, korzhik, Вы писали:
K>>только начал знакомиться с Erlang. Сразу возник вопрос: есть ли какие нибудь реализации Erlang способные запускаться на NVidia CUDA ?
BZ>рискуя отгадать, предположу, что ты незнаком со спецификацией этих процессоров. именно у таких людей возникаюь гениальные идеи о переносе всего вподряд под sse, cuda и порчие ускорители интернета
я разве просил тебя делать какие то предположения?
Здравствуйте, korzhik, Вы писали:
K>я разве просил тебя делать какие то предположения?
значит, я не ошибся таким как вы даже не вдомёк, что cuda — это вариация на тему sse, и независимо исполняющихся ветвей кода там в 8 раз меньше, чем якобы существующих прцессоров. плюс к этому явная иерархия памяти, сравнительно низкие частоты и т.п., что делает самый мощный gf примерно аналогом блумберга по скорости, но на порядок более сложно программируемым (увы и ах, даже С-компилятора под эту архитектуру нет). разумеется, речь идёт о general purpose задачах, не перемножении матриц
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, korzhik, Вы писали:
K>>я разве просил тебя делать какие то предположения?
BZ>значит, я не ошибся таким как вы даже не вдомёк, что cuda — это вариация на тему sse, и независимо исполняющихся ветвей кода там в 8 раз меньше, чем якобы существующих прцессоров. плюс к этому явная иерархия памяти, сравнительно низкие частоты и т.п., что делает самый мощный gf примерно аналогом блумберга по скорости, но на порядок более сложно программируемым (увы и ах, даже С-компилятора под эту архитектуру нет). разумеется, речь идёт о general purpose задачах, не перемножении матриц
это всё понятно. уже прочитал по ссылке которую посоветовал Курилка.
Не понятно остаётся только откуда столько пренебрежения к собеседнику, то есть ко мне, и откуда столько злорадства?
Здравствуйте, korzhik, Вы писали:
K>это всё понятно. уже прочитал по ссылке которую посоветовал Курилка. K>Не понятно остаётся только откуда столько пренебрежения к собеседнику, то есть ко мне, и откуда столько злорадства?
Здравствуйте, BulatZiganshin, Вы писали:
K>>я разве просил тебя делать какие то предположения?
BZ>значит, я не ошибся таким как вы даже не вдомёк, что cuda — это вариация на тему sse, и независимо исполняющихся ветвей кода там в 8 раз меньше, чем якобы существующих прцессоров.
А таким как ты вдомек, что CUDA это вариация на тему kernel-stream, а не SSE? Наверное, такие как ты не в курсе, что в 10 DirectX поддерживаются _независимые_ ветвления для шейдерных процессоров, и что каждый из этих процов внутри — векторный навроде SSE, чем и заканчивается сходство?
Короче, зачем выеживаться, Булат? По простому сказать не можешь? Думаешь, тебя тонким слоем на бутерброд раскатать нельзя при желании? Да запросто.
Здравствуйте, Gaperton, Вы писали:
G>А таким как ты вдомек, что CUDA это вариация на тему kernel-stream, а не SSE?
и конечно, ламеру это скажет много больше, чем SSE
G>Короче, зачем выеживаться, Булат? По простому сказать не можешь? Думаешь, тебя тонким слоем на бутерброд раскатать нельзя при желании? Да запросто.
усложнять просто, упрощать сложно. заметь, он даже мои максимально упрощённые объяснения не воспринял — это для него в любом случае тёмный лес. таким можно только сказать "низя" и сослаться на какого-нибудь авторитета (вроде тебя ). желания прочесть несколько десятков страниц у него так и не возникло, лучше он здесь митинговать будет
Здравствуйте, BulatZiganshin, Вы писали:
G>>А таким как ты вдомек, что CUDA это вариация на тему kernel-stream, а не SSE?
BZ>и конечно, ламеру это скажет много больше, чем SSE
Ламер это явление преходящее, а не орден на всю жизнь за заслуги. Сегодня он ламер, а завтра — прочитал про kernel-stream, SSE, научился, и уже не ламер.
Блин, да пусть он даже и ламер с орденом (чего мы знать не можем), зачем ему-то об этом говорить? Он же не воинствующий, не закоренелый в своих убеждениях ламер, на людей не бросается, и социально не опасен, так?
G>>Короче, зачем выеживаться, Булат? По простому сказать не можешь? Думаешь, тебя тонким слоем на бутерброд раскатать нельзя при желании? Да запросто.
BZ>усложнять просто, упрощать сложно. заметь, он даже мои максимально упрощённые объяснения не воспринял — это для него в любом случае тёмный лес. таким можно только сказать "низя" и сослаться на какого-нибудь авторитета (вроде тебя ). желания прочесть несколько десятков страниц у него так и не возникло, лучше он здесь митинговать будет
А может быть, все-таки можно? Допустим, мы при большом желании можем сделать трансляцию _подмножества_ Erlang в эти kernel-stream, хоть это и не просто — но теоретически возможно? Чтобы хост-программа работала на нормальном проце, а streaming-алгоритмы описывались на том же Эрланге, но с некоторыми ограничениями?
Здравствуйте, BulatZiganshin, Вы писали:
BZ>таким можно только сказать "низя" и сослаться на какого-нибудь авторитета (вроде тебя ).
И кстати — я в этих вопросах далего не гуру, скорее сам — ламер. Вот Зефиров (thesz) — он гуру. И мне кажется, он уже думал над задачей, как транслировать Хаскель в kernel-stream .
Ну вот смотри — быстрый поверхностный взгляд. stream — это преобразование map на наборе данных. kernel — ассоциативная и коммутативная функция, сводящая результат к одному числу, ну или к другому, меньшему набору данных. Чисто теоретически (уверен, что и практически) — это можно красиво выразить через comprehensions, воспользовавшись вашими ацкими монадами и do-синтаксисом. И сделать монадный подъязык описания функций kernel и stream.
В случае Эрланга можно поступить так же, введя какие-нибудь хитрые комбинаторы для описания kernel-stream конструкций, и определив какие-нить хитрые "процессы", которые (с подмножеством языка) работают на шейдерных процессорах (не знаю точно как, думать лень). Интересная задача получается, не так ли? Понятно, что из этого может что-то получится.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, korzhik, Вы писали:
K>>я разве просил тебя делать какие то предположения?
BZ>значит, я не ошибся таким как вы даже не вдомёк, что cuda — это вариация на тему sse, и независимо исполняющихся ветвей кода там в 8 раз меньше, чем якобы существующих прцессоров.
Кстати, сейчас посмотрел — модель выполнения CUDA гораздо гибче, чем GPGPU и шейдеры DirectX 10. Там настоящие треды выполняются, они могут сами лазить в общую память и даже пользоваться явной барьерной синхронизацией, и их там до 12 тыщ выполняется одновременно. Ничего общего с SSE, и гораздо больше, чем kernel-stream, о котором писал я. Молодцы nVidia.
Единственно — треды "легкие", в том смысле, что оперируют только на локальной памяти видеоускорителя, и выполняют только "сигнальную" потоковую обработку. Однако, процессы Эрланга туда положить вполне возможно, хоть и с рядом ограничений. Ну очень подходящими выглядят для этого кудовские треды, прям как доктор прописал.
Добавлю, что в ветке обсуждения из erlang-мэйллиста, которую дал Курилка, ссылку на куду дал Влад Диметреску. Который _далеко_ не лох, Булат.
Так что кончай чморить парня, и занимайся сам RTFM-ом .
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, Gaperton, Вы писали:
G>>А таким как ты вдомек, что CUDA это вариация на тему kernel-stream, а не SSE?
BZ>и конечно, ламеру это скажет много больше, чем SSE
Булат, чтож ты злобный то такой. Давно я не встречал таких воинствующих зазнаек. Надеюсь не все функциональщики такие
В чём то я конечно ламер, в чём то нет. Но это не главное.
Главное тут то, что стиль общения, который ты демонстрируешь, очень портит атмосферу на таком замечательном ресурсе как rsdn.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>Здравствуйте, korzhik, Вы писали:
K>>>я разве просил тебя делать какие то предположения?
BZ>>значит, я не ошибся таким как вы даже не вдомёк, что cuda — это вариация на тему sse, и независимо исполняющихся ветвей кода там в 8 раз меньше, чем якобы существующих прцессоров.
G>Кстати, сейчас посмотрел — модель выполнения CUDA гораздо гибче, чем GPGPU и шейдеры DirectX 10. Там настоящие треды выполняются, они могут сами лазить в общую память и даже пользоваться явной барьерной синхронизацией, и их там до 12 тыщ выполняется одновременно. Ничего общего с SSE, и гораздо больше, чем kernel-stream, о котором писал я. Молодцы nVidia.
G>Единственно — треды "легкие", в том смысле, что оперируют только на локальной памяти видеоускорителя, и выполняют только "сигнальную" потоковую обработку. Однако, процессы Эрланга туда положить вполне возможно, хоть и с рядом ограничений. Ну очень подходящими выглядят для этого кудовские треды, прям как доктор прописал.
G>Добавлю, что в ветке обсуждения из erlang-мэйллиста, которую дал Курилка, ссылку на куду дал Влад Диметреску. Который _далеко_ не лох, Булат.
G>Так что кончай чморить парня, и занимайся сам RTFM-ом .
Вот Булат, учись стилю общения у Gaperton'а
В общем спасибо всем, очень заинтерисовали. Пойду читать доки.
Здравствуйте, Gaperton, Вы писали:
G>Кстати, сейчас посмотрел — модель выполнения CUDA гораздо гибче, чем GPGPU и шейдеры DirectX 10. Там настоящие треды выполняются, они могут сами лазить в общую память и даже пользоваться явной барьерной синхронизацией, и их там до 12 тыщ выполняется одновременно. Ничего общего с SSE, и гораздо больше, чем kernel-stream, о котором писал я. Молодцы nVidia.
тяжёлый случай. сначала написал, что я неправ, затем пошёл разбираться. 12к тредов выполняются как ты понимаешь не одномоментно, более того каждые 8 процов выполняют одну и ту же команду (это кстати почему я сравниваю с sse, врожде здесь ламеры уже в курсе, что general-pupose ПО не выигрывает от замечтаельной возможности делать 8 умножений одновременно). учитывая разницу в частотах, можешь посчитать, насколько скорость выше нехалема. по моим прикидкам скорость выше раза в 3, в частности память там могутная. но это — при условии программирования на асме
что касается реализации хаскела, которую ты описываешь, то я ничего не понял. ndp там понятно будет очень неплохо смотреться, и это имхо вполне реально, кто-то этим наверняка занимается. как general-purpose дробилка лучше будет выглядеть larrabee, я полагаю
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, Gaperton, Вы писали:
G>>Кстати, сейчас посмотрел — модель выполнения CUDA гораздо гибче, чем GPGPU и шейдеры DirectX 10. Там настоящие треды выполняются, они могут сами лазить в общую память и даже пользоваться явной барьерной синхронизацией, и их там до 12 тыщ выполняется одновременно. Ничего общего с SSE, и гораздо больше, чем kernel-stream, о котором писал я. Молодцы nVidia.
BZ>тяжёлый случай. сначала написал, что я неправ, затем пошёл разбираться.
Да ты палюбому неправ . Ты неправ даже если говорить об обычных DirectX 9/10 видеокартах, принципы функционирования которых мне знакомы. И ты ваще канкретно неправ, если говорить о CUDA, которая оказалась существенно лучше, чем обычный DirectX.
Разумеется, сейчас ты стремительно ликвидируешь лоховство, лихорадочно читая документацию . Но от судьбы не уйдешь, Булат. Я этим элементарно дольше занимался, мы даже простой DX8.1 видеоконтроллер проектировали как-то с Зефировым .
BZ>12к тредов выполняются как ты понимаешь не одномоментно, более того каждые 8 процов выполняют одну и ту же команду (это кстати почему я сравниваю с sse, врожде здесь ламеры уже в курсе, что general-pupose ПО не выигрывает от замечтаельной возможности делать 8 умножений одновременно). учитывая разницу в частотах, можешь посчитать, насколько скорость выше нехалема. по моим прикидкам скорость выше раза в 3, в частности память там могутная. но это — при условии программирования на асме
12К тредов шедулятся _аппаратно_. Такое количество тредов необходимо для того, чтобы убрать латентность памяти. Потому, что внутри шейдерной программы разрешено совершенно свободно обращатся к памяти — это тебе не убогий DirectX с kernel-stream, это CUDA. В результате, в отличии от нехалема, они показывают реальную производительность существенно более близкую к пиковой. Я думаю, там не менее 80% КПД, а то и больше, на полную катушку задействуя широкую шину в память. В Нехалеме не так. Во-первых, сравни пропускные способности памятей. Во-вторых, учти, что в CUDA этот широкий канал задействован на полную катушку — она прожует _все_ данные с этой шины на полной скорости, и не подавится.
Далее. То, что ты говоришь, что они одну и ту же команду выполняют — это было так в старых видеокартах DX8.1, где не было человеческих условных переходов (выполнялись обе ветки, и результат дискардился — представь себе оператор ? в языке С со строгой семантикой). К твоему сведению, в DirectX 10, которому соответствует CUDA, это уже не так, или, по крайней мере, не совсем так. Переходы там человеческие. А устройство конвейра тебе никто не покажет, чтоб ты смог понять, как именно они сделали . Это секрет. В случае видеокарт конвейр скрывается более тщательно, чем в случае обычных процов. Скажем, они могут группировать несколько ядер на один конвейр, но если они задействуют предсказатель переходов в шедулере (а переходы предсказываются с высокой вероятностью, более 90%), то расклад совсем другой выходит. Хрен ты это заметишь, что они группируют.
В результате, возьми пиковую производительность типичного процессора CUDA, вычти оттуда процентов 10-20, и ты получишь реальную. В случае нехалема будет _далеко_ не так. Особенно, если на нем прогнать что-нибудь веселое, на данных, не влезающих в кэш, типа фурье-адамара, на котором он с причмокиванием всосет по производительности раз в 10. И это не единственная такая задача.
BZ>что касается реализации хаскела, которую ты описываешь, то я ничего не понял. ndp там понятно будет очень неплохо смотреться, и это имхо вполне реально, кто-то этим наверняка занимается. как general-purpose дробилка лучше будет выглядеть larrabee, я полагаю
Знаешь, честно, я не в курсе ваших Хаскелевых терминов . Ламер, сам понимаешь. А вот то что kernel-stream отлично в функциональных терминах выражается, это факт медицинский. Однако, CUDA не ограничена простым kernel-stream, как DirectX 9. Она позволяет писать в шейдерах по человечески, почти ни в чем себе не отказывая.
Здравствуйте, Gaperton, Вы писали:
G>Единственно — треды "легкие", в том смысле, что оперируют только на локальной памяти видеоускорителя, и выполняют только "сигнальную" потоковую обработку. Однако, процессы Эрланга туда положить вполне возможно, хоть и с рядом ограничений. Ну очень подходящими выглядят для этого кудовские треды, прям как доктор прописал.
Если бы ещё на CUDA нормально целая арифметика работала
Хотя... После парсера XML с поддержкой SSE я уже ничему не удивлюсь.
Здравствуйте, Gaperton, Вы писали:
G>Разумеется, сейчас ты стремительно ликвидируешь лоховство, лихорадочно читая документацию . Но от судьбы не уйдешь, Булат. Я этим элементарно дольше занимался, мы даже простой DX8.1 видеоконтроллер проектировали как-то с Зефировым .
во-первых, я этим никогда серьёзно не занимался. прочёл описание архитектуры чтобы оценить как там будут выглядеть архиваторы — вот и всё
G>В результате, возьми пиковую производительность типичного процессора CUDA, вычти оттуда процентов 10-20, и ты получишь реальную.
а мужики-то не знают. по всему видно, что ты в отличие от меня даже это описание до конца не прочитал. успехов тебе в ускорении интернета
таким как вы даже не вдомёк, что cuda — это вариация на тему sse, и независимо исполняющихся ветвей кода там в 8 раз меньше, чем якобы существующих прцессоров. плюс к этому явная иерархия памяти, сравнительно низкие частоты и т.п., что делает самый мощный gf примерно аналогом блумберга по скорости, но на порядок более сложно программируемым (увы и ах, даже С-компилятора под эту архитектуру нет). разумеется, речь идёт о general purpose задачах, не перемножении матриц 
). желания прочесть несколько десятков страниц у него так и не возникло, лучше он здесь митинговать будет
