Re[20]: Nim lang
От: WolfHound  
Дата: 14.12.18 13:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

WH>>В теории. А на практике грамотно сделанное детерминированное удаление всегда быстрее.

S>Непонятно, как можно быть меньше, чем 0.
Ты не посчитал количество вызовов ГЦ. А это весьма дорогая процедура.
В случае с детерминированным удалением в большинстве случаев их вообще не будет.
А в тех случаях, когда без ГЦ никак их будет намного меньше.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: Nim lang
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.12.18 05:21
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Ты не посчитал количество вызовов ГЦ. А это весьма дорогая процедура.
WH>В случае с детерминированным удалением в большинстве случаев их вообще не будет.
WH>А в тех случаях, когда без ГЦ никак их будет намного меньше.
Во-первых, это опять зависит от количества удаляемых обьектов.
Во-вторых, чтобы обеспечить уменьшение вызовов ГЦ, нам нужно научиться выполнять выделение на reclaimed памяти, а это — удорожание каждого выделения. Ведь в чисто-GC сценарии выделение стоит O(1) и с очень небольшой константой.
Я сходу даже не рискну написать неравенство, чтобы прикинуть соотношение параметров, при котором детерминированное удаление будет в целом быстрее.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Nim lang
От: Ночной Смотрящий Россия  
Дата: 17.12.18 18:16
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Вроде еще где-то проскакивала информация, что гарантия не только по памяти, что сравнительно легко достигается в C++ если писать с нуля, но ещё и гарантия по дедлокам, что уже реально выглядит как фича-убийца.


Гарантия дедлоков эквивалентна проблеме останова со всеми вытекающими
Re[16]: Nim lang
От: alex_public  
Дата: 18.12.18 11:45
Оценка:
Здравствуйте, WolfHound, Вы писали:

_>>Эм, и как ты вообще можешь сравнивать некую абстрактную концепцию работы с коллекциями (следующий уровень абстракции над понятием итератор) с отдельным специализированным языком, заточенным на решение SIMD задач? Между ними если и будет когда-то какая-то связь, то исключительно "дружеская" (скажем можно будет написать на Halide какой-то алгоритм, работающий с данными в виде диапазонов) и уж точно не "конкуренция".

WH>Если мы говорим про засунуть код в GPU, то они решают одну и ту же исходную задачу. Только Halide намного мощнее.

В приведённой презентации (ты похоже её даже не посмотрел) вообще не было собственно GPU кода. Там речь шла о том, что если вдруг потребуется написать подобный код, то он отлично интегрируется в конвейер обработки данных на Ranges.
Re[17]: Nim lang
От: alex_public  
Дата: 18.12.18 12:32
Оценка:
Здравствуйте, WolfHound, Вы писали:

_>>Это ещё зачем? Архитектурно в этом нет никакого смысла — будут недостатки от обеих существующих схем (с RAII или без).

WH>За тем, что просто удалять память намного проще чем удалять память, вызывая при этом, какой то код.
WH>И недостатков я не вижу. Попробуй придумать сценарий, в котором объект с дуструктором должен быть вне стека.

Смотри, единственным недостатком классического подхода RAII в данном контексте является вроде как медленное освобождение памяти, из-за того, что для каждого объекта вызывается его деструктор. Но в реальности для большинства кода (при правильной современной архитектуре) это не так: если ты будешь хранить в каком-нибудь std::vector набор структур с пустым деструктором, то при удаление этого вектора оптимизатор вырежет не только вызов к пустой функции, но и вообще весь этот цикл. Ненужное (когда деструктор не делает ничего полезного, но всё равно вызывается) замедление возможно только в случае использования полиморфных объектов с виртуальными деструкторами.

В то же время предложенный тобой вариант будет эффективно работать только в том случае, если на уровне типов запретить выделять в данном пуле (или GC, не суть) память для объектов с деструкторами. Т.е. этот метод уже не будет работать для тех областей кода, в которых нам нужны объекты обоих типов (с RAII и без — ты же хотел поддерживать и тех и тех, правильно?), т.к. проверка на тип объекта будет даже медленнее чем обращение к пустому виртуальному деструктору.

По сумме этих двух пунктов, получаем что предложенный подход (с одновременным использованием объектов с RAII и без, разделяемых системой типов) будет иметь какие-то преимуществ в быстродействие на столько ничтожном проценте возможных задач, что нет никакого смысла в его реализации.
Re[19]: Nim lang
От: alex_public  
Дата: 18.12.18 12:59
Оценка: +1
Здравствуйте, anton_t, Вы писали:

_>>Мдаа, ты снова умудрился показать не сопоставление с образцом, а какую-то ненужную ерунду. А всего то стоило проставить значение у какой-нибудь из переменных в образце (как в примере на Эрланге или в примере 18-14 на Расте). Я начинаю думать, что ты реально не понимаешь смысл технологии сопоставления с образцом.

_>Когда на плюсах реализуешь этот "смешной код", тогда и поговорим.

Твой "сложнейший" код на большинстве языков программирования записывается как "red=cp.c.r;". Говорить о том, что сопоставление с образцом нужно для решения этой "задачки" — это просто феерическое непонимание. Причём непонимание как сопоставления с образцом, так и структурного связывания: это разные технологии с разными задачами, но обе эти задачи очень далеки от показанной тобой глупости.

Структурное связывание в C++ (и во многих других языках, например в Питоне) создано для удобного написания такого кода:
pair<Result, ErrorCode> F()
{
    //...
    return {r, e};
}
auto [r, e]=F();


Сопоставление с образом в том же Rust'е помогает в написание кода такого вида (как видно, нет никаких намёков на "деструкцию" — это всего лишь одна из опций):
fn main() {
    let x = Some(5);
    let y = 10;

    match x {
        Some(50) => println!("Got 50"),
        Some(y) => println!("Matched, y = {:?}", y),
        _ => println!("Default case, x = {:?}", x),
    }
    println!("at the end: x = {:?}, y = {:?}", x, y);
}
Re[17]: Nim lang
От: WolfHound  
Дата: 18.12.18 16:11
Оценка:
Здравствуйте, alex_public, Вы писали:

_>В приведённой презентации (ты похоже её даже не посмотрел) вообще не было собственно GPU кода. Там речь шла о том, что если вдруг потребуется написать подобный код, то он отлично интегрируется в конвейер обработки данных на Ranges.

Я всё посмотрел.
Но ты подменяешь задачу одним из возможных решений.
Если у нас встал вопрос с GPU значит изначальная задача: быстро перемолотить большую пачку данных.
А это означает, что нужно сразу брать правильный инструмент.
Ибо данная библиотека в самом лучшем для неё случае сыграет с Halide в ничью.
Просто по тому, что Halide позволяет задавать план исполнения руками.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Nim lang
От: WolfHound  
Дата: 18.12.18 17:11
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Смотри, единственным недостатком классического подхода RAII в данном контексте является вроде как медленное освобождение памяти, из-за того, что для каждого объекта вызывается его деструктор. Но в реальности для большинства кода (при правильной современной архитектуре) это не так:

И что это за правильная архитектура такая?

_>В то же время предложенный тобой вариант будет эффективно работать только в том случае, если на уровне типов запретить выделять в данном пуле (или GC, не суть) память для объектов с деструкторами. Т.е. этот метод уже не будет работать для тех областей кода, в которых нам нужны объекты обоих типов (с RAII и без — ты же хотел поддерживать и тех и тех, правильно?), т.к. проверка на тип объекта будет даже медленнее чем обращение к пустому виртуальному деструктору.

1)Все проверки в моём варианте исключительно статические. Соответственно скорость работы в самом худшем случае будет как у rust'а.
2)В моём варианте память это не ресурс. Соответственно объектов с деструктором становится примерно 0. Сколько я писал на .НЕТ IDisposable был реализован у ничтожного количества объектов.
И я ни разу не хранил такие объекты. 100% случаев выглядело примерно так.
      using (StreamReader sr = new StreamReader(filename))
      {
         txt = sr.ReadToEnd();
      }


_>По сумме этих двух пунктов, получаем что предложенный подход (с одновременным использованием объектов с RAII и без, разделяемых системой типов) будет иметь какие-то преимуществ в быстродействие на столько ничтожном проценте возможных задач, что нет никакого смысла в его реализации.

Ты очень сильно недооцениваешь количество сценариев, где мой подход будет работать.
Например, почти любой парсинг. После разбора мы получаем некую структуру, которая состоит из кучи гетерогенных объектов связанных между собой. Далее почти всегда мы эту структуру только читаем. И после окончания работы всю структуру разом грохаем.
Другой пример формирование запроса к БД. Сначала мы формируем АСТ запроса, оптимизируем его, потом формируем SQL для БД. После чего нам АСТ и ошмётки оптимизации этого АСТ не нужны. Их можно разом грохнуть.

А теперь ты покажи задачу, в которой нужно хранить объект с деструктором не на стеке.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Nim lang
От: WolfHound  
Дата: 18.12.18 17:18
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Гарантия дедлоков эквивалентна проблеме останова со всеми вытекающими

Но, как и в случае с остановкой программы есть варианты, допускающие ложноположительные срабатывания и не допускающие ложноотрицательные.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Nim lang
От: alex_public  
Дата: 18.12.18 23:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

_>>В приведённой презентации (ты похоже её даже не посмотрел) вообще не было собственно GPU кода. Там речь шла о том, что если вдруг потребуется написать подобный код, то он отлично интегрируется в конвейер обработки данных на Ranges.

WH>Я всё посмотрел.
WH>Но ты подменяешь задачу одним из возможных решений.
WH>Если у нас встал вопрос с GPU значит изначальная задача: быстро перемолотить большую пачку данных.
WH>А это означает, что нужно сразу брать правильный инструмент.

Если говорить о правильных инструментах для вычислениях на GPU, то в случае требования максимальной производительности у меня будет выбор между CUDA и OpenCL (в зависимости от целевого железа). Если чуть снять требования на производительность, то можно использовать OpenCL на всём железе.

Ну а если вообще сосредоточиться на простоте кодирования и наплевать на возможность тонкой оптимизации, то можно глянуть на OpenACC.

Это вот реальные инструменты для вычислений на GPU, хотя речь в данной дискуссии была совсем не о них.

WH>Ибо данная библиотека в самом лучшем для неё случае сыграет с Halide в ничью.

WH>Просто по тому, что Halide позволяет задавать план исполнения руками.

Какая библиотека то? )))
Re[19]: Nim lang
От: alex_public  
Дата: 18.12.18 23:25
Оценка:
Здравствуйте, WolfHound, Вы писали:

_>>Смотри, единственным недостатком классического подхода RAII в данном контексте является вроде как медленное освобождение памяти, из-за того, что для каждого объекта вызывается его деструктор. Но в реальности для большинства кода (при правильной современной архитектуре) это не так:

WH>И что это за правильная архитектура такая?

В которой динамический полиморфизм применяется только в тех случаях, когда он реально необходим (весьма редко на самом деле), а не по всякому чиху.

_>>В то же время предложенный тобой вариант будет эффективно работать только в том случае, если на уровне типов запретить выделять в данном пуле (или GC, не суть) память для объектов с деструкторами. Т.е. этот метод уже не будет работать для тех областей кода, в которых нам нужны объекты обоих типов (с RAII и без — ты же хотел поддерживать и тех и тех, правильно?), т.к. проверка на тип объекта будет даже медленнее чем обращение к пустому виртуальному деструктору.

WH>1)Все проверки в моём варианте исключительно статические. Соответственно скорость работы в самом худшем случае будет как у rust'а.

Всё верно, будет та же самая максимальная скорость, что в C++ или Rust'e. Соответственно возникает вопрос — а зачем нам какая-то более сложная система, если существующие и так уже работают точно так же?

WH>2)В моём варианте память это не ресурс. Соответственно объектов с деструктором становится примерно 0. Сколько я писал на .НЕТ IDisposable был реализован у ничтожного количества объектов.

WH>И я ни разу не хранил такие объекты. 100% случаев выглядело примерно так.
WH>
WH>      using (StreamReader sr = new StreamReader(filename))
WH>      {
WH>         txt = sr.ReadToEnd();
WH>      }
WH>


Ну видимо потому, что реального RAII в .Net нет, а его бледные подобия дико неудобны. )))

_>>По сумме этих двух пунктов, получаем что предложенный подход (с одновременным использованием объектов с RAII и без, разделяемых системой типов) будет иметь какие-то преимуществ в быстродействие на столько ничтожном проценте возможных задач, что нет никакого смысла в его реализации.

WH>Ты очень сильно недооцениваешь количество сценариев, где мой подход будет работать.

Ещё раз: работать он будет практически везде. Вопрос в том будет ли он хоть где-то превосходить существующие системы...

WH>Например, почти любой парсинг. После разбора мы получаем некую структуру, которая состоит из кучи гетерогенных объектов связанных между собой. Далее почти всегда мы эту структуру только читаем. И после окончания работы всю структуру разом грохаем.

WH>Другой пример формирование запроса к БД. Сначала мы формируем АСТ запроса, оптимизируем его, потом формируем SQL для БД. После чего нам АСТ и ошмётки оптимизации этого АСТ не нужны. Их можно разом грохнуть.
WH>А теперь ты покажи задачу, в которой нужно хранить объект с деструктором не на стеке.

Эм, ты похоже всё перепутал. Здесь у нас вообще то речь шла о другом твоём подходе (у тебя в изначальном сообщение было несколько предложений). С идеей о том, чтобы убивать разом некие кучи логически связанных между собой объектов, я никогда не спорил — она абсолютно верная. Более того, она прямо сейчас эффективно используется (только без всяких гарантий от компилятора) в некоторых C++ проектах. А здесь мы обсуждали твою идею с разделением (с помощью системы типов) всех объектов на имеющих и не имеющих деструкторы. Такая смесь подходов на мой взгляд не принесёт вообще никаких преимуществ.
Re[19]: Nim lang
От: WolfHound  
Дата: 19.12.18 01:26
Оценка: +1
Здравствуйте, alex_public, Вы писали:

_>Это вот реальные инструменты для вычислений на GPU, хотя речь в данной дискуссии была совсем не о них.

В теории самые быстрые программы на ассемблере. А на практике попытки обогнать современные компиляторы мало кто может.
С Halide ситуация ещё хуже.
Просто за счёт того что на нем можно перебрать не один десяток планов исполнения за день. А руками у тебя будет уходить несколько дней на один план исполнения.
А производительность кода зависит от плана исполнения намного сильнее, чем от микрооптимизаций. А если быстрейший план упирается в пропускную способность памяти, то от них вообще ничего не зависит.

_>Какая библиотека то? )))

Та, про которую он говорил. Ибо просто взять и закинуть код в GPU может сработать только для наиболее примитивных случаев.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Nim lang
От: WolfHound  
Дата: 19.12.18 01:26
Оценка:
Здравствуйте, alex_public, Вы писали:

WH>>И что это за правильная архитектура такая?

_>В которой динамический полиморфизм применяется только в тех случаях, когда он реально необходим (весьма редко на самом деле), а не по всякому чиху.
Простейший пример: Дерево разбора программы. Как ты собираешься его представлять в "правильной архитектуре"? Без выделения кучи отдельных объектов?

WH>>1)Все проверки в моём варианте исключительно статические. Соответственно скорость работы в самом худшем случае будет как у rust'а.

_>Всё верно, будет та же самая максимальная скорость, что в C++ или Rust'e. Соответственно возникает вопрос — а зачем нам какая-то более сложная система, если существующие и так уже работают точно так же?
Нет. Не верно. Ты вообще прочитал, что я написал?
В С++ ты можешь сделать то о чем я говорю. Но не будет никаких гарантий со стороны компилятора.
А вот в расте нет.
Там система типов обязывает удалять каждый объект.

_>Ну видимо потому, что реального RAII в .Net нет, а его бледные подобия дико неудобны. )))

Нет. По тому, что объекты с деструкторами нужны только на стеке.
Показать пример, когда это не так ты не можешь. Вот и юлишь.

_>Эм, ты похоже всё перепутал. Здесь у нас вообще то речь шла о другом твоём подходе (у тебя в изначальном сообщение было несколько предложений). С идеей о том, чтобы убивать разом некие кучи логически связанных между собой объектов, я никогда не спорил — она абсолютно верная. Более того, она прямо сейчас эффективно используется (только без всяких гарантий от компилятора) в некоторых C++ проектах. А здесь мы обсуждали твою идею с разделением (с помощью системы типов) всех объектов на имеющих и не имеющих деструкторы. Такая смесь подходов на мой взгляд не принесёт вообще никаких преимуществ.

Я ничего не перепутал.
Для того чтобы убивать объекты пачками нужна гарантия отсутствия там деструкторов.
Причём не только из-за производительности но главное из-за того что не понятно в каком порядке эти деструкторы вызывать.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Nim lang
От: alex_public  
Дата: 21.12.18 12:15
Оценка:
Здравствуйте, WolfHound, Вы писали:

_>>Какая библиотека то? )))

WH>Та, про которую он говорил. Ибо просто взять и закинуть код в GPU может сработать только для наиболее примитивных случаев.

Так в том то и дело, что в презентации речь шла не про какую-то конкретную библиотеку, а про интерфейс к любым подобным библиотекам (в том числе возможно и на Halide написанным, хотя тут он мне кажется излишним и правильнее будет OpenCL).
Re[21]: Nim lang
От: alex_public  
Дата: 21.12.18 12:45
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

_>>В которой динамический полиморфизм применяется только в тех случаях, когда он реально необходим (весьма редко на самом деле), а не по всякому чиху.

WH>Простейший пример: Дерево разбора программы. Как ты собираешься его представлять в "правильной архитектуре"? Без выделения кучи отдельных объектов?

Вообще то это как раз не простейший пример, а довольно редкий случай. Но возможно и в нём нет никаких проблем — надо смотреть. Я с данной областью плотно не работал, так что расскажи откуда там по твоему возникают основные проблемы эффективной работы с памятью.

WH>>>1)Все проверки в моём варианте исключительно статические. Соответственно скорость работы в самом худшем случае будет как у rust'а.

_>>Всё верно, будет та же самая максимальная скорость, что в C++ или Rust'e. Соответственно возникает вопрос — а зачем нам какая-то более сложная система, если существующие и так уже работают точно так же?
WH>Нет. Не верно. Ты вообще прочитал, что я написал?
WH>В С++ ты можешь сделать то о чем я говорю. Но не будет никаких гарантий со стороны компилятора.

Да.

WH>А вот в расте нет.

WH>Там система типов обязывает удалять каждый объект.

В Rust'е есть режим C/C++ под названием unsafe. )))

_>>Ну видимо потому, что реального RAII в .Net нет, а его бледные подобия дико неудобны. )))

WH>Нет. По тому, что объекты с деструкторами нужны только на стеке.
WH>Показать пример, когда это не так ты не можешь. Вот и юлишь.

Ну для начала "на стеке" — это довольно широкое понятие. К примеру выделенное "на стеке" функции main по сути является глобальной переменной.

Далее, я так понимаю, что тебя интересуют примеры объектов в куче, деструкторы которых используются не только для управления памятью? Ну вот тебе элементарный пример: пишем приложение, являющееся контейнером OLE-объектов (ну грубо говоря свой Word). В таком приложение у нас естественно где-то внутри должен быть динамический список неких обёрток вокруг COM-интерфейсов, обеспечивающих как удобный доступ к их функциональности, так и автоматическое освобождение...

_>>Эм, ты похоже всё перепутал. Здесь у нас вообще то речь шла о другом твоём подходе (у тебя в изначальном сообщение было несколько предложений). С идеей о том, чтобы убивать разом некие кучи логически связанных между собой объектов, я никогда не спорил — она абсолютно верная. Более того, она прямо сейчас эффективно используется (только без всяких гарантий от компилятора) в некоторых C++ проектах. А здесь мы обсуждали твою идею с разделением (с помощью системы типов) всех объектов на имеющих и не имеющих деструкторы. Такая смесь подходов на мой взгляд не принесёт вообще никаких преимуществ.

WH>Я ничего не перепутал.
WH>Для того чтобы убивать объекты пачками нужна гарантия отсутствия там деструкторов.
WH>Причём не только из-за производительности но главное из-за того что не понятно в каком порядке эти деструкторы вызывать.

Ну т.е. по факту из плюсов:
— гарантии компилятора на безопасное уничтожение пула.
Из минусов:
— невозможность использования объектов с деструктором
— усложнение системы типов (возможно приводящее к написанию большого количества лишнего кода, как в Rust'e).

Не уверен, что плюсы тут перевешивают минусы. В особенности с учётом того, что сам подход с мгновенным убийством пула объектов нужен в небольшом проценте приложений (где можно "пострадать" и без гарантий).
Re[22]: Nim lang
От: WolfHound  
Дата: 22.12.18 17:26
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Вообще то это как раз не простейший пример, а довольно редкий случай.

Да ладно. Почти все приложения что-то парсят.

_>Но возможно и в нём нет никаких проблем — надо смотреть. Я с данной областью плотно не работал, так что расскажи откуда там по твоему возникают основные проблемы эффективной работы с памятью.

Я уже говорил. Тут нужно выделить кучу объектов. А потом всю кучу грохнуть.

WH>>А вот в расте нет.

WH>>Там система типов обязывает удалять каждый объект.
_>В Rust'е есть режим C/C++ под названием unsafe. )))
Зачем в этом случае нам вообще rust?

_>Далее, я так понимаю, что тебя интересуют примеры объектов в куче, деструкторы которых используются не только для управления памятью? Ну вот тебе элементарный пример: пишем приложение, являющееся контейнером OLE-объектов (ну грубо говоря свой Word). В таком приложение у нас естественно где-то внутри должен быть динамический список неких обёрток вокруг COM-интерфейсов, обеспечивающих как удобный доступ к их функциональности, так и автоматическое освобождение...

Это суровое легаси. Вокруг которого можно поплясать с бубном.
В нормальном ГУИ будет просто память.

_> — усложнение системы типов (возможно приводящее к написанию большого количества лишнего кода, как в Rust'e).

Нет. Приводящее к значительно меньшим проблемам, чем система rust'а.
Например, вот этой проблемы вообще не будет.
http://smallcultfollowing.com/babysteps/blog/2018/11/10/after-nll-moving-from-borrowed-data-and-the-sentinel-pattern/

_>Не уверен, что плюсы тут перевешивают минусы. В особенности с учётом того, что сам подход с мгновенным убийством пула объектов нужен в небольшом проценте приложений (где можно "пострадать" и без гарантий).

Небольшом? Да они почти все такие, если посмотреть внимательно.
Все веб серверы и прочие запрос/ответ серверы и клиенты, все морды к базам данных,...
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: Nim lang
От: WolfHound  
Дата: 22.12.18 17:26
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Так в том то и дело, что в презентации речь шла не про какую-то конкретную библиотеку, а про интерфейс к любым подобным библиотекам (в том числе возможно и на Halide написанным, хотя тут он мне кажется излишним и правильнее будет OpenCL).

То есть ты даже не посмотрел что такое Halide, а рассуждать лезешь.
Реалии современного железа таковы что для того чтобы получить высокопроизводительный алгоритм нужно выбрать правильный план исполнения.
В данный момент в общем случае оптимальный план исполнения можно подобрать только тупым перебором. Просто пробуя разные планы и замеряя время исполнения.
Halide позволяет разогнать этот процесс в сотню раз.
В Halide есть автопланировщик, но он далеко не всегда позволяет найти оптимальный план исполнения. Но для фазы прототипирования алгоритма сойдет.

А OpenCL этот как раз вариант руками на ассемблере. В теории самый быстрый, а на практике...

Ну и главное совершенно не понятно, что за библиотеку ты собрался писать на Halide или OpenCL?
В лекции говорится про возможность взять несколько фильтров и слепить из них один. После чего запустить его на ГПУ. Для этого придётся написать компилятор, который компилирует эти фильтры в Halide, OpenCL или что-то ещё.
И тут мы опять возвращаемся к плану исполнения. И если у Halide есть автопланировщик который что-то может, то в случае с OpenCL мы приплыли. Нам сначала придётся написать Halide с автопланировщиком.
И первые строки на сайте Halide:

Halide is a programming language designed to make it easier to write high-performance image and array processing code on modern machines. Halide currently targets:
• CPU architectures: X86, ARM, MIPS, Hexagon, PowerPC
• Operating systems: Linux, Windows, macOS, Android, iOS, Qualcomm QuRT
• GPU Compute APIs: CUDA, OpenCL, OpenGL, OpenGL Compute Shaders, Apple Metal, Microsoft Direct X 12

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: Nim lang
От: Evgeny.Panasyuk Россия  
Дата: 05.01.19 18:21
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Для того чтобы убивать объекты пачками нужна гарантия отсутствия там деструкторов.


static_assert(std::is_trivially_destructible_v<T>);
Re[22]: Nim lang
От: WolfHound  
Дата: 05.01.19 19:21
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

WH>>Для того чтобы убивать объекты пачками нужна гарантия отсутствия там деструкторов.

EP>
EP>static_assert(std::is_trivially_destructible_v<T>);
EP>

Причем тут С++? Ты вообще прочитал о чём разговор?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: Nim lang
От: Слава  
Дата: 05.01.19 20:12
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Причем тут С++? Ты вообще прочитал о чём разговор?


Было бы замечательно, если бы вы собрали ваши мысли о новом способе управления памятью: из тех трёх эпичных постов, из прочих тредов, и оформили бы это в единую статью с Q&A в конце.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.