Здравствуйте, Кодт, Вы писали:

К>А, понял, что ты хочешь.
К>Чтобы был один поток инструкций, а все разветвления оказались чисто в данных.

Да, SIMD жеж...
На самом деле немного мешает то, что на CUDA нельзя писать боле или менее С+ код.
Понятно, что всю мощь полимрфизма не развернуть, и нужны какие-то ограничения, и, возможно, поддержка в коде (например разметка, какие реализации виртуального метода тут допустимы), но это всё равно не тоже самое, что совсем другая реализация на случай SIMD...

К>1) По-прежнему, виртуальная машина. Может быть, какая-то совсем примитивная, типа форта или лиспа.
Не понятно зачем. По идее, мы же компилячим ядра при загрузке в SIMD, так что что даст в. машина?
Или имеется в виду некий интерпретатор просто? Типа код один, а управление в данных?

К>2) Сериализация: однотипные данные обрабатываются параллельно (SIMD), разнотипные — сперва один компонент одним способом, остальные компоненты не меняются, затем второй компонент вторым способом, и т.д.
Ну я что-то такое и думал, только я бы ещё научил компиллер так компилячить код альтернативных методов, что бы можно было его максимально переиспользовать во всех потоках. Ну, типа есть у нас инструкция "прибавить то к этому", и надо что-то к чему-то прибавить в трёх альтернативах из пяти. Ну мы подгоняем нужные аргумент, в каждом по очереди, а потом прибавляем сразу во всех. За одно данные прокачаться успеют...

К>3) Асинхронное переупорядочивание: как только встретили разнотипные данные, — положить компоненты в очереди обработчиков соответствующего типа. Т.е. механизм отправки сообщений.

Тут, скорее всего, будет оч. дорогие штрафы за хаотичный доступ к памяти...

Здравствуйте, Erop, Вы писали:
E>На самом деле немного мешает то, что на CUDA нельзя писать боле или менее С+ код.
смысл Cuda вот в чем
вот ты решил что-то распареллелить на 100 тысяч потоков. ты же не сможешь написать просто физически руками отдельный код для каждого из 100 тысяч потоков? код будет для каждого потока один. или по крайней мере будет несколько групп потоков с общим кодом.

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

Здравствуйте, __kot2, Вы писали:

__>смысл Cuda вот в чем
<...>
__>не надо вкорячивать в каждый поток свою мегалогику, которая будет как-то там с другими потоками со своей мегалогикой взаимодействовать. такое в 100 тысяч независимых потоков не запустишь

А смысл "этюда" состоит в вопросе, что делать, если, хоть и нельзя, но всё равно очень хочется привинтить ООП, хотя бы на полшишечки...

Здравствуйте, Erop, Вы писали:

E>А смысл "этюда" состоит в вопросе, что делать, если, хоть и нельзя, но всё равно очень хочется привинтить ООП, хотя бы на полшишечки...

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

Здравствуйте, Кодт, Вы писали:

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

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Ikemefula, Вы писали:

I>>Умеет. Последовательные вычисления на симд получаются адски дорогими. mp — это и ежу понятно.

E>Синтаксические конструкции похожие будут... Ну, например, в куске кода, где возможны виртуальные вызовы, наверное надо будет перечислять доступные реализации...

Ага. Т.е. иерархии будут не открытыми, как в привычном ООП, а закрытые, как в ФП. Только, в отличие от ФП, не будет функционального типа ни в каком виде, бо функциональный тип — это пара { указатель_на_функцию, контекст }.

На уровне идеи — для полиформизма используется размеченное объединение.

Пусть будет такой исходник:

class Base {
    virtual int calc() { return 0; }
};

class Derived : public Base {
    virtual int calc() override { return Base::calc() + 1; }
};

...
Base * base = getObj();
return base->calc();

Его реализация:

class Base
{
   void * typeId_;    

   static void __call_virtual__calc(Base * obj) 
   {
      switch(typeId_)
      {
      case __type_id__Base: return obj->calc();
      case __type_id__Derived: return static_cast<Derived*>(obj)->calc();
      default: terminate(__type_id__Base, "__call_virtual__calc");
      }
   }

    /* virtual */ int calc() { return 0; }
};

class Derived : public Base {
    /* virtual */ int calc() { return Base::calc() + 1; }
};

...
Base * base = getObj();
return Base::__call_virtual__calc(base);

Проблемы "открытых" иерархий у вас существовать не должны, т.к. не должно быть динамической подгрузки кода, а в статически собранном модуле все иерархии будут "закрытыми", т.е. switch(typeId_) будет заведомо полным и terminate вывалится только при порче памяти. Одно "но" — вся эта "открытость/закрытость" должна будет разруливаться на этапе, который сейчас называют линковкой. ))

Здравствуйте, Кодт, Вы писали:

К>Можно, конечно, для каждого семейства косвенно вызываемых функций (каждый виртуальный метод; каждая сигнатура функций, на которые берутся указатели) делать своего диспетчера. Это будет выполняться быстрее

Именно так.


К>зато для компилятора и линкера работы прибавится.

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

Здравствуйте, Erop, Вы писали:

E>Предположим, что мы хотим сделать транслятор С++-like языка под CUDA или другую SIMD платформу.
E>Существенным ограничением является то, что там нельзя вызывать код по указателю.

Можно делать косвенный call, но нельзя делать косвенный jump.

Syntax

// direct call to named function, func is a symbol
call{.uni} (ret-param), func, (param-list);
call{.uni} func, (param-list);
call{.uni} func;

// indirect call via pointer, with full list of call targets
call{.uni} (ret-param), fptr, (param-list), flist;
call{.uni} fptr, (param-list), flist;
call{.uni} fptr, flist;

// indirect call via pointer, with no knowledge of call targets
call{.uni} (ret-param), fptr, (param-list), fproto;
call{.uni} fptr, (param-list), fproto;
call{.uni} fptr, fproto;

E>Как там сделать хотя бы скромный полиморфизм?

Вот так и сделать.

Здравствуйте, vdimas, Вы писали:
V>Можно делать косвенный call, но нельзя делать косвенный jump.
чтобы не запоминать кучу аких ньюансов достаточно просто помнить, что у всех тредов (точнее у большого блока тредов) будет один instruction pointer.
и если один тред зашел в ф-ию, то остальные треды тоже идут в эту ф-ию, просто результаты выполнения маскируются и она выполняется вхолостую. то же самое с любые бранчем в if, если у тебя для части тредов if срабатывает, а для одного только треда else, то сначала выполнится if для всех, потом else для всех

Здравствуйте, __kot2, Вы писали:

__>чтобы не запоминать кучу аких ньюансов достаточно просто помнить, что у всех тредов (точнее у большого блока тредов) будет один instruction pointer.

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

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

Здравствуйте, Erop, Вы писали:

E>Навеяно этим вопросом

Автор: sergey2b
Дата: 07.02.16

на собеседовании.

E>Предположим, что мы хотим сделать транслятор С++-like языка под CUDA или другую SIMD платформу.
E>Существенным ограничением является то, что там нельзя вызывать код по указателю.

E>Как там сделать хотя бы скромный полиморфизм? Я думаю, что органично предлагать решения на С++, но главное тут не язык, а идеи

Когда я смотрел в КУДУ, там ещё и стэка/функций не было. Все функции всегда инлайнились. Хотя это не мешает. использовать рекурсивные алгоритмы.

Как сейчас не знаю.

Здравствуйте, Erop, Вы писали:

E>Ну, иногда, хочется... Вот у тебя надо чего-то сделать с кучей примитивов трёх типов, например вычислить тень. Отличается небольшая только часть кода, специфичная для примитива.

Извиняюсь за оффтопик. Ты вроде раньше языками занимался. А сейчас считаешь презренные тени. Сменил область?

Здравствуйте, alpha21264, Вы писали:

A>Извиняюсь за оффтопик. Ты вроде раньше языками занимался. А сейчас считаешь презренные тени. Сменил область?

Нет, просто интересная задачка...

Здравствуйте, Erop, Вы писали:

E>Как там сделать хотя бы скромный полиморфизм? Я думаю, что органично предлагать решения на С++, но главное тут не язык, а идеи
"Я нашел, как применить здесь нестирающиеся шины из полиструктурного волокна с вырожденными аминными связями и неполными кислородными группами. Но я не знаю пока, как использовать регенерирующий реактор на субтепловых нейтронах"
Вы не могли бы привести пример задачи, которую вы хотите решать?
Затем можно думать про то, каким синтаксисом стоит это выражать, и во что это будет компилироваться.
Просто я уверен, что, скажем, рендеринг веб-страничек засовывать в куду не имеет никакого смысла.

Здравствуйте, Erop, Вы писали:

E>Тут правда так мало людей не знают, что такое SIMD и google?

Зато патриотов завались.

Я думаю, для SIMD ООП не нужен от слова совсем, а вот какой-нибудь декларативный dataflow язык как раз будет в тему.