конвертация в строку аттоматически в 10 переводит

А какая разница, в какой СИ число? В памяти всё равно одинаково хранится.

https://github.com/nlohmann/json/releases/tag/v3.0.0

https://github.com/nlohmann/json/releases/tag/v3.0.0

NaN and infinity values can now be stored inside the JSON value without throwing an exception. They are, however, still serialized as null Гм, странное решение

NaN and infinity values can now be stored inside the JSON value without throwing an exception. They are, however, still serialized as null Гм, странное решение

Ну, почему оно не сериализуется — это понятно (в стандарте JSON нет значений NaN и Inf). А вот зачем их при этом хранить в памяти, и какое должно быть поведение — это вопрос дискуссионный.

Ну, почему оно не сериализуется — это понятно (в стандарте JSON нет значений NaN и Inf). А вот зачем их при этом хранить в памяти, и какое должно быть поведение — это вопрос дискуссионный.

А я знаю библиотеки, где сериализуется... гм. Зависит от задачи, наверное.

Ну, эти библиотеки не следуют стандарту, вот и всё. Если тебе нужно вопреки стандарту с такими значениями работать — то ок, они тебе годятся.

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

NaN короче)

Ну, почему оно не сериализуется — это понятно (в стандарте JSON нет значений NaN и Inf). А вот зачем их при этом хранить в памяти, и какое должно быть поведение — это вопрос дискуссионный.

Ну, внутри оно использует самый обычный double для хранения.

Если оно может представлять Inf и NaN — значит может хранить.

https://developer.nvidia.com/cuda-toolkit/whatsnew

https://developer.nvidia.com/cuda-toolkit/whatsnew

@isenbaev

https://developer.nvidia.com/cuda-toolkit/whatsnew

Есть же OpenCL 2.2. Там можно даже на чём-то похожем на C++14 писать.

Есть же OpenCL 2.2. Там можно даже на чём-то похожем на C++14 писать.

никогда с такими вещами не работал. но подозреваю, что CUDA будет шустрее 😊

никогда с такими вещами не работал. но подозреваю, что CUDA будет шустрее 😊

Это слова человека, который топит за кроссплатформу?

Это слова человека, который топит за кроссплатформу?

ты не подумай, что я против OpenCL 😊

и от своей веры в кроссплатформу я не отрекаюсь

Это слова человека, который топит за кроссплатформу?

но куда шустрее, не важно что ты за человек

но куда шустрее, не важно что ты за человек

Кто бы сомнивался, что реалиазация vendor-lock технологии будет быстрее, чем реализация общего стандарта.)

кстати, никто не в курсе, как там война Vulkan vs DirectX?

кстати, никто не в курсе, как там война Vulkan vs DirectX?

Как и обычная OGL vs D3D

Кто бы сомнивался, что реалиазация vendor-lock технологии будет быстрее, чем реализация общего стандарта.)

сомневайся не сомневайся, а жертвовать производильностью ради идеологии готовы не многие

так бы конечно я б на риск 5 сидел бы

сомневайся не сомневайся, а жертвовать производильностью ради идеологии готовы не многие

Тут даже спорить особо смысла нет.)

Поздравляю, у нас два верующих человека в чате!

как двумерным массив хранится в памяти? я думал что как последовательность элементов, т.е. если массив mas[2][2] и я обращусь к *mas[2] то получу mas[2][0] но нет, выводит мусор, получается нельзя работать с двумерным массивом как с одномерным через указатели?

как двумерным массив хранится в памяти? я думал что как последовательность элементов, т.е. если массив mas[2][2] и я обращусь к *mas[2] то получу mas[2][0] но нет, выводит мусор, получается нельзя работать с двумерным массивом как с одномерным через указатели?

По порядку хранится. То есть, сначала элементы из первого ряда, потом из второго и тд.

как двумерным массив хранится в памяти? я думал что как последовательность элементов, т.е. если массив mas[2][2] и я обращусь к *mas[2] то получу mas[2][0] но нет, выводит мусор, получается нельзя работать с двумерным массивом как с одномерным через указатели?

не мусор а сслыку на первый элемент третьей строки по идее

если это не массив массивов, то должен последовательно в едином куске памяти

как двумерным массив хранится в памяти? я думал что как последовательность элементов, т.е. если массив mas[2][2] и я обращусь к *mas[2] то получу mas[2][0] но нет, выводит мусор, получается нельзя работать с двумерным массивом как с одномерным через указатели?

Просто надо не *mas[2], а (*mas)[2]

да, так работает, а на что я получил указатель?

да, так работает, а на что я получил указатель?

Подожди, ты там просто за массив выходил. Первый элемент второго столбца - *mas[1]

вернее на вторую строку 1 элемент

А то, что я сказал - это просто третий элемент

(что в этом случае одно и то же)

это абстрактный пример, в моем случае все ок сработало с (*mas)[i]

это абстрактный пример, в моем случае все ок сработало с (*mas)[i]

Но помни, что это даёт i-тый элемент массива, как если бы он был не двумерным, а одномерным.

да мне это и нужно, мне нужно циклически подвинуть двумерную матрицу, и я подумал что проще это сделать оперируя одномерной послдовательностью

да, так работает, а на что я получил указатель?

ты получил указатель на ячейку в памяти в которой лежит значение

Ну, почему оно не сериализуется — это понятно (в стандарте JSON нет значений NaN и Inf). А вот зачем их при этом хранить в памяти, и какое должно быть поведение — это вопрос дискуссионный.

Во всех 3х стандартах ?

https://godbolt.org/g/qdaaZP Это я что-то не так делаю или проблема в компиляторе? Компилится только в GCC 8.0 и MSVC

Мой GCC, судя по всему, внезапно считает, что там у нас pair<const int, unique_ptr<int>>

И отказывается генерировать даже move, что разумно

Мой GCC, судя по всему, внезапно считает, что там у нас pair<const int, unique_ptr<int>>

Да, на GCC 7.2 у меня то же самое

Локально простыми средствами без map воспроизвести не удалось

Мой GCC, судя по всему, внезапно считает, что там у нас pair<const int, unique_ptr<int>>

так и надо же

ваще надо p.emplace(1, std::make_unique<int>(5));

Судя по всему, если не указываешь явно, то некоторые компиляторы делают deduce на const int и, очевидно, падают

а остальные, видимо, считают, что это обычный int

ваще надо p.emplace(1, std::make_unique<int>(5));

не спорю )

Судя по всему, если не указываешь явно, то некоторые компиляторы делают deduce на const int и, очевидно, падают

там должен быть value_type

а value_type это pair<const T, U>

а хотя я кажется вру

The overload (2) is equivalent to emplace(std::forward<P>(value)) and only participates in overload resolution if std::is_constructible<value_type, P&&>::value == true

а нет не вру

мыж не передаем туда pair

Кто бы сомнивался, что реалиазация vendor-lock технологии будет быстрее, чем реализация общего стандарта.)

Я бы сомневался.

Во всех 3х стандартах ?

Я знаю только RFC 8259, там прям чёрным по белому указано: > Numeric values that cannot be represented in the grammar below (such > as Infinity and NaN) are not permitted. А какие ещё есть стандарты на JSON? Давайте обсудим!

Я бы сомневался.

и тем не менее, куда быстрее)

и тем не менее, куда быстрее)

Буду продолжать сомневаться, пока мне не покажут бенчмарк.

(не то чтобы кто-то обязан мне что-то показывать, просто сомневаюсь и всё)

Кстати да, было бы интересно посмотреть на бенчмарки

Буду продолжать сомневаться, пока мне не покажут бенчмарк.

Ну, свежих мало.

Будто забили.

Я бы сомневался.

nvidia остановилась на стандарте openCL 1.2. Что по нынешним меркам эпоха динозавров. Новых бенчей ты врядли найдёшь. Могу только точно сказать что если похоже реализовать один и тот же алгоритм хеширования на cuda и на opencl для зелёных, то cuda будет шустрее. Ну и под cuda писать приятнее. OpenCL лямку по больше степени только AMD сейчас и тянет.

А можно (имеет ли смысл) писать под гпу без всех этих фреймворков?

всмысле фреймворков?

cuda/Opencl это апи для вычислительных задач на GPU

cuda/Opencl это апи для вычислительных задач на GPU

Читал, что это фреймворки

ты можешь писать рассчёты через opengl шейдеры, вот только скорость тебя расстроит. compute shaders opengl я правда не смотрел

ну в общем ниже особо спускаться то и некуда.

Кстати, об OpenCL... Реально ли реализовать поддержку стандартов через CUDA?

Я думаю находясь вне Nvidia эта затея обречена на боль и страдания.

Тот же device-side enqueue поддерживается в Cuda C(Если если мне память не имзеняет). Но сделать это не имея доступа к исходникам драйвера/cuda compiler будет непросто и скорее всего надо будет просто транслятор из одного в другое. Ну нафиг.

AMD у себя в rocm делает обратное :) Чтобы прогнав через hip компилятор можно было Cuda C код запускать не только на nvidia.

Да, эту новость слышал где-то год (вроде) назад. Но там так и не понял, они выложили сорцы или нет.

Большая часть доступна. Вроде HIP полностью рабочий в opensource. Есть некоторые части драйвера которые доступны только под NDA, но вроде компилятор opencl и hip полность в open source. 100% гарантии не даю https://llvm.org/docs/AMDGPUUsage.html https://github.com/ROCm-Developer-Tools/HIP https://github.com/ROCm-Developer-Tools https://github.com/RadeonOpenCompute https://rocm.github.io/

Там есть некий cycl

https://www.khronos.org/sycl

есть какая-нибудь тула для анализа качества CMake файлов? например, лишние либы в линковке или инклудах и тд