Здравствуйте, 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, и ты получишь реальную.
а мужики-то не знают. по всему видно, что ты в отличие от меня даже это описание до конца не прочитал. успехов тебе в ускорении интернета
Здравствуйте, BulatZiganshin, Вы писали:
G>>Разумеется, сейчас ты стремительно ликвидируешь лоховство, лихорадочно читая документацию . Но от судьбы не уйдешь, Булат. Я этим элементарно дольше занимался, мы даже простой DX8.1 видеоконтроллер проектировали как-то с Зефировым .
BZ>во-первых, я этим никогда серьёзно не занимался. прочёл описание архитектуры чтобы оценить как там будут выглядеть архиваторы — вот и всё
Ну вот, не занимался — а на людей, которые вопросы задают, пальцем показываешь, что мол идиоты. Нехорошо себя ведешь, Булат. Как типичный воинствующий ламер. Не люблю это.
G>>В результате, возьми пиковую производительность типичного процессора CUDA, вычти оттуда процентов 10-20, и ты получишь реальную.
BZ>а мужики-то не знают. по всему видно, что ты в отличие от меня даже это описание до конца не прочитал. успехов тебе в ускорении интернета
Конечно не знают, откуда тебе знать-то. По всему видно, что ты описание вообще не читал, а если читал, то не понял ничего. Ничо, я тебе разъясню. Потоковые процессорные архитектуры всегда проектируются так, чтобы быть сбалансированными . Понимаешь, Булат? Им нет смысла делать шину памяти шире, чем проц способен прожевать, благо что это для потокового проца довольно легко считается, и идиотов отступать от этого правила в nVidia и удорожать проц на ровном месте нет .
Все GPU всегда были сбалансированными, есть, и будут . Это с обычными, не мультитредными процами не так, а с GPU и разного рода Ниагарами — так. Ниагара дает средний "кпд" до 70-80% на реальных задачах, а у этих штук он одназначно больше by design.
Успехов тебе дальше в этой, как ее... пенисометрии. На людей только не бросайся больше, ладно? А то придется опять тебе доказывать, что ты ламер.
BZ>>таким можно только сказать "низя" и сослаться на какого-нибудь авторитета (вроде тебя ).
G>И кстати — я в этих вопросах далего не гуру, скорее сам — ламер. Вот Зефиров (thesz) — он гуру. И мне кажется, он уже думал над задачей, как транслировать Хаскель в kernel-stream .
Это, *ля, п+-$^ц получается, да.
Если быть кратким.
Тяжело. В K/S отображается очень мало типичных Хаскельных вычислений. Но при желании можно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Gaperton, Вы писали:
G>Все GPU всегда были сбалансированными, есть, и будут .
для задач ускорения графики — да. то что при этом 8 устройств должны исполнять одну и ту же команду — для GPU вполне нормально
ускорение графики лучше кешируется, чем наши типичные задачи, к тому же кеши gf специализированы именно для его графических расчётов. от обращения в память в первую очередь требуется высокая пропускная способность, поэтому за такт gf280 считывает 512 байт. по скорости же произвольного доступа он от силы вдвое быстрее нехалема
Здравствуйте, BulatZiganshin, Вы писали:
BZ>усложнять просто, упрощать сложно. заметь, он даже мои максимально упрощённые объяснения не воспринял — это для него в любом случае тёмный лес. таким можно только сказать "низя" и сослаться на какого-нибудь авторитета (вроде тебя ). желания прочесть несколько десятков страниц у него так и не возникло, лучше он здесь митинговать будет
Булат, если не сбавишь обороты, то мне придется помочь. Ламеры, не ламеры, но людей нужно уважать. Он же тебе не хамил и не покалывал?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
The Intel XML Software Suite is a comprehensive suite of C++ and Java* software-based runtime libraries for Linux* and Windows* operating systems. The Intel XML Software Suite is standards compliant, to allow for easy integration into existing XML environments and is optimized for future Intel processors implementing the new Intel® Streaming SIMD Extensions (Intel® SSE) instructions and other features, to deliver extended capabilities, enhanced performance and greater energy efficiency for many applications.
Здравствуйте, VladD2, Вы писали:
BZ>>усложнять просто, упрощать сложно. заметь, он даже мои максимально упрощённые объяснения не воспринял — это для него в любом случае тёмный лес. таким можно только сказать "низя" и сослаться на какого-нибудь авторитета (вроде тебя ). желания прочесть несколько десятков страниц у него так и не возникло, лучше он здесь митинговать будет
VD>Булат, если не сбавишь обороты, то мне придется помочь. Ламеры, не ламеры, но людей нужно уважать. Он же тебе не хамил и не покалывал?
Влад, я с каждым человеком разговариваю на его языке. пока что на хамство жаловались только вы с гапертоном
что касается этого чела, то не вижу никаких проблем в том, чтобы ламера назвать ламером. ты вот например ламер в ФП — ты ж на это не обижаешься?
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Влад, я с каждым человеком разговариваю на его языке. пока что на хамство жаловались только вы с гапертоном
Я с ними соглашусь, Булат
Но это всё оффтопик и лучше обсуждать вне форума.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Влад, я с каждым человеком разговариваю на его языке. пока что на хамство жаловались только вы с гапертоном
ОК. Почему же данный случай стал исключением?
BZ>что касается этого чела, то не вижу никаких проблем в том, чтобы ламера назвать ламером. ты вот например ламер в ФП — ты ж на это не обижаешься?
Конечно, не обижаюсь. Я же понимаю, что со мной говорит ламер в человеческом общении и вообще человек зазнавшийся и чем-то озлобленный. Не обижайся и ты, я тоже люблю правду матку резать.
Но данное понимание никак не влияет на мои решения, так как они сугубо прагматичны. По этому, чтобы закрыть этот вопрос на будущее, давай я тебе объясню свои предпосылки.
Итак... Я исхожу исключительно из соображений "полезности для сайта". Так вот яркие личности воде тебя и Гапертона несомненно полезны для сайта, так как в их ответах и вопросах много интересного. Но для сайта так же важно чтобы с него не бежали новички. Понятно к чему я виду?
Одна яркая личность не стоит 1000 новичков которые будут отпугнуты от сайта.
Собственно кого-то другого я бы тупо забанил и все. Тебе же я делю предупреждение. Но если ты его проигнорируешь, то придется тебя банить.
Можешь спросить в Гапертона, он тебе подтвердит. Я никого не пугаю и слов на ветер не бросаю и на пару дней не баню. Так что будь добр, если чувствуешь, что хочется ответить кому-то гадость, просто не отвечай. Оценивай мысли, а не людей их изрекающих.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Итак... Я исхожу исключительно из соображений "полезности для сайта". Так вот яркие личности воде тебя и Гапертона несомненно полезны для сайта, так как в их ответах и вопросах много интересного. Но для сайта так же важно чтобы с него не бежали новички. Понятно к чему я виду? VD>Одна яркая личность не стоит 1000 новичков которые будут отпугнуты от сайта. VD>Собственно кого-то другого я бы тупо забанил и все. Тебе же я делю предупреждение. Но если ты его проигнорируешь, то придется тебя банить.
Яркая не яркая — здесь уже не причем ИМХО, более правильно оценивать поступки, в контексте ситауции, конечно. Сморим. Он же ничего полезного не сказал? Нет, не сказал. Его кто-то провоцировал? Нет. Переход на личности сразу был? Был. Имеем — ничем не мотивированный, голый наезд. Смягчающие обстоятельства есть? Никаких. Мягко урезонить пытались? Пытались. Факт раскаяния был? Нет.
Приняв во внимание все обстоятельства дела, коллегия присяжных рекомендует пару дней бана. Але, присяжные? Что скажете?
Здравствуйте, Gaperton, Вы писали:
G>Приняв во внимание все обстоятельства дела, коллегия присяжных рекомендует пару дней бана. Але, присяжные? Что скажете?
В коллегию присяжных допускаются только те, кто был судим не менее трех раз, и оттянул совокупный срок не меньше недели . Только они тонко понимают Понятия, на основании которых действуют модераторы, и особенно — пункт 5 из Свода Понятий.
Здравствуйте, Gaperton, Вы писали:
G>>Приняв во внимание все обстоятельства дела, коллегия присяжных рекомендует пару дней бана. Але, присяжные? Что скажете?
G>В коллегию присяжных допускаются только те, кто был судим не менее трех раз, и оттянул совокупный срок не меньше недели . Только они тонко понимают Понятия, на основании которых действуют модераторы, и особенно — пункт 5 из Свода Понятий.
Ну, еще можно добавить, что присяжный не должен находится в бане, и должен иметь рейтинг не менее 1000, то есть быть уважаемым, законопослушным членом сообщества — по крайней мере, в этот момент. А тот, кто кроме перечисленного, смог хотя бы раз отмазаться от бана по каналу moderator@rsdn.ru, получает почотное звание Авторитета.
Здравствуйте, Gaperton, Вы писали:
G>Яркая не яркая — здесь уже не причем ИМХО, более правильно оценивать поступки, в контексте ситауции, конечно. Сморим. Он же ничего полезного не сказал? Нет, не сказал. Его кто-то провоцировал? Нет. Переход на личности сразу был? Был. Имеем — ничем не мотивированный, голый наезд. Смягчающие обстоятельства есть? Никаких. Мягко урезонить пытались? Пытались. Факт раскаяния был? Нет.
Тут все просто. Если оценивать так как ты горишь, то тут пол форуму, включая тебя, придется забарабанить.
Лично мне раскаяния ни чьи не нужны. Мне нужно чтобы впредь подобного было меньше. Надеюсь он меня понял.
У всех бывает плохое настроение... в конце концов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>Яркая не яркая — здесь уже не причем ИМХО, более правильно оценивать поступки, в контексте ситауции, конечно. Сморим. Он же ничего полезного не сказал? Нет, не сказал. Его кто-то провоцировал? Нет. Переход на личности сразу был? Был. Имеем — ничем не мотивированный, голый наезд. Смягчающие обстоятельства есть? Никаких. Мягко урезонить пытались? Пытались. Факт раскаяния был? Нет.
VD>Тут все просто. Если оценивать так как ты горишь, то тут пол форуму, включая тебя, придется забарабанить.
Это, мягко говоря, не правда. В подавляющем большинстве случаев в начале есть провокация, в том или ином виде. Случаи же, когда в ответ на простой вопрос происходит наезд — крайне редки, а я этого не делал вообще никогда.
Отличие, знаешь-ли, примерно как между статьями УК "грабеж" и "разбой".
VD>Лично мне раскаяния ни чьи не нужны. Мне нужно чтобы впредь подобного было меньше. Надеюсь он меня понял. VD>У всех бывает плохое настроение... в конце концов.
Это всем нужно. И _такое_ "плохое настроение" вполне можно пересидеть в бане. В конце концов, ничего такого особо страшного в бане нет, особенно если человек ее на 100% заслужил. Это мне кажется. Но решать, разумеется, тебе, твоя кухня.
таким как вы даже не вдомёк, что cuda — это вариация на тему sse, и независимо исполняющихся ветвей кода там в 8 раз меньше, чем якобы существующих прцессоров. плюс к этому явная иерархия памяти, сравнительно низкие частоты и т.п., что делает самый мощный gf примерно аналогом блумберга по скорости, но на порядок более сложно программируемым (увы и ах, даже С-компилятора под эту архитектуру нет). разумеется, речь идёт о general purpose задачах, не перемножении матриц 
). желания прочесть несколько десятков страниц у него так и не возникло, лучше он здесь митинговать будет
