и вызове конструктора данные сначала копируются в его контекст, а потом героически переносятся в объект.
Да, это действительно очень непривычно для тех, кто не знаком с мув-семантикой, и кажется, что происходит так как вы написали. Но в реальности, всё лучше: данные копируются или муваются в его контекст. И вот второй случай как раз благоприятный для нас. А если данные не смогли мувнуться в конструктор - что ж, значит копирования не избежать. Тогда в принципе без разницы, в какой момент сделать это копирование: при переносе в контекст конструктора, или внутри конструктора.
move-семантика не такая самоочевидная штука, и нужно неплохо вникнуть в неё, чтобы понять, что передача по значению - единственный верный способ в современном C++.
А мы не сравнивали C++ и Java) Мы сравнивали оверхэд в этих языках. Если сохранить size(), то оверхед цикла по диапазону может только вырасти сильнее. И да, мы сравнивали непрогретый цикл на Java с непрогретым на Java. Так что результат на мой взгляд репрезентативен
Хороший вопрос, как связаны копирование и сборщик мусора. Объясняю. Часто копировать приходится, потому что нужно передать владение объектом. В модели со сборщиком мусора объектом владеет глобальный пул и передавать владение не нужно. В модели без сборщика мусора - нужно) Отсюда копирования.
Согласен, без веб-ссылки выглядит не очень, добавим.
С openCL не сталкивался, но знаю что для CUDA есть готовые примитивы редукции
Прям примитивов наколько я знаю нет, но есть много библиотек. Как ни удивительно, но редукцию часто реализуют сами.
Но да, пример конечно учебный. Показывает, что даже такая простая операция как сумма имеет массу нюансов.
А на какой карте вы это заметили?
На разных. Везде результаты примерно одинаковые, но касаются это не всех задач. Поэтому я высказал предположение, что это зависит от того, насколько вы хорошо нагружаете видеокарту. Если нагружаете хорошо (что сложно), то вполне возможно накладные расходы победят.
Спасибо за замечание! Эта статья - развёрнутый конспект вебинара, поэтому в ней приведены скриншоты презентации. Да, это не очень удобно, но зато так доступно выделение отдельных идентификаторов цветом, что было важно.
Код в текстовом виде есть в репозитории, ссылка на который - в конце статьи.
Так это не приговор, а определение об обеспечительных мерах, которое вступает в силу сразу же.
И почему-то мало кто обращает внимание на важную деталь. Запрещено использовать указанное словосочетание только в качестве ключевых слов. Прямого запрета выдавать эти слова не содержится в определении.
Спасибо за замечание! Одна из основных идей этой вводной статьи - показать, что сравнение действительно некорректно. Несмотря на то, что по измеримым характеристикам (флопсы) GPU во много раз превосходит CPU, последний нельзя заменить на первый. Причина - их действительно не во всех случаях можно сравнивать.
Но если задача действительно допускает массовый параллелизм, хорошо ложится на видеокарту, правильно реализована на ней, то тогда сравнение обретает смысл: соотношение времени её работы на CPU и GPU получится примерно такое как теоретическое отношение производительности этих устройств.
Гораздо большее изумление вызывает, что не добавили элементарную конвертацию LE <-> BE.
Если конечно её действительно нет, потому что это уж очень странно выглядит, что enum для Endian добавлен, а такой простой и нужной функции нет.
Комитет решил, что сборка мусора не нужна, и убрал её не далее, как два дня назад. Да-да, сюрприз, сборка мусора была, но ей по факту никто не пользовался. Поэтому комитет не стал делать её даже deprecated, а сразу исключил из Стандарта.
Хватит с нас и умных указателей. По факту, сборка мусора приносит гораздо больше проблем, чем пользы. Особенно, если мусора нет.
Да, это действительно очень непривычно для тех, кто не знаком с мув-семантикой, и кажется, что происходит так как вы написали. Но в реальности, всё лучше: данные копируются или муваются в его контекст. И вот второй случай как раз благоприятный для нас. А если данные не смогли мувнуться в конструктор - что ж, значит копирования не избежать. Тогда в принципе без разницы, в какой момент сделать это копирование: при переносе в контекст конструктора, или внутри конструктора.
move-семантика не такая самоочевидная штука, и нужно неплохо вникнуть в неё, чтобы понять, что передача по значению - единственный верный способ в современном C++.
С почётом приму эту должность)
А мы не сравнивали C++ и Java) Мы сравнивали оверхэд в этих языках. Если сохранить size(), то оверхед цикла по диапазону может только вырасти сильнее. И да, мы сравнивали непрогретый цикл на Java с непрогретым на Java. Так что результат на мой взгляд репрезентативен
Спасибо, да, опечатка)
Да, в бенчмарках я заботился о том, чтобы оптимизатор не выоптимизировал то, что измеряется)
В Java не выводится, но разница во времени означает, что цикл выполнялся
Да, к сожалению... Поэтому про модули не упоминал
Если вам было смешно, то это тоже успех
Хороший вопрос, как связаны копирование и сборщик мусора. Объясняю. Часто копировать приходится, потому что нужно передать владение объектом. В модели со сборщиком мусора объектом владеет глобальный пул и передавать владение не нужно. В модели без сборщика мусора - нужно) Отсюда копирования.
Спасибо, хорошее замечание!
Спасибо за ценные замечания!
Согласен, без веб-ссылки выглядит не очень, добавим.
Прям примитивов наколько я знаю нет, но есть много библиотек. Как ни удивительно, но редукцию часто реализуют сами.
Но да, пример конечно учебный. Показывает, что даже такая простая операция как сумма имеет массу нюансов.
На разных. Везде результаты примерно одинаковые, но касаются это не всех задач. Поэтому я высказал предположение, что это зависит от того, насколько вы хорошо нагружаете видеокарту. Если нагружаете хорошо (что сложно), то вполне возможно накладные расходы победят.
Спасибо за замечание! Эта статья - развёрнутый конспект вебинара, поэтому в ней приведены скриншоты презентации. Да, это не очень удобно, но зато так доступно выделение отдельных идентификаторов цветом, что было важно.
Код в текстовом виде есть в репозитории, ссылка на который - в конце статьи.
Так это не приговор, а определение об обеспечительных мерах, которое вступает в силу сразу же.
И почему-то мало кто обращает внимание на важную деталь. Запрещено использовать указанное словосочетание только в качестве ключевых слов. Прямого запрета выдавать эти слова не содержится в определении.
Спасибо за замечание! Одна из основных идей этой вводной статьи - показать, что сравнение действительно некорректно. Несмотря на то, что по измеримым характеристикам (флопсы) GPU во много раз превосходит CPU, последний нельзя заменить на первый. Причина - их действительно не во всех случаях можно сравнивать.
Но если задача действительно допускает массовый параллелизм, хорошо ложится на видеокарту, правильно реализована на ней, то тогда сравнение обретает смысл: соотношение времени её работы на CPU и GPU получится примерно такое как теоретическое отношение производительности этих устройств.
Действительно проморгал. Расскажете подробнее? Желательно с ссылками
Если конечно её действительно нет, потому что это уж очень странно выглядит, что enum для Endian добавлен, а такой простой и нужной функции нет.
Хватит с нас и умных указателей. По факту, сборка мусора приносит гораздо больше проблем, чем пользы. Особенно, если мусора нет.
Рефлешн ждём)
А Microsoft действительно молодцы. Поддержали почти всё. У них кстати есть своя актуальная таблица соответствия.