Rust сообщество

Может, кто-то знает есть ли какие-то сообщества по Rust в Украине? Митапы? Хоть что-нибудь? 🙂

👍НравитсяПонравилось0
В избранноеВ избранном2
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Го парад звучить хіпстєрнєє

dou.ua/...​rums/topic/31540/#1943645
коменты не читай
@
сразу отвечай

а вообще криптоаферисты, я б с такими в одном чате не сидел бы

коменты не читай
@
сразу отвечай

совершенно верно.. я не буду искать дубликаты среди 98 месседжей

Зашел посмотреть на Rust сообщество, а увидел «экспертов». Только я не понял, а какой язык программирования «эксперты» создали?

А почему у сишников от руста так бомбит?

Тогда не совсем понятно: вельми знать си, знать раст и уметь в интероп между ними — намного лучшая позиция с т.з. жоб секьюрити

Есть информации что сидетья на сях и кукарекать какой раст плохой намного легче, чем сидеть на сях и параллельно учить раст.

Теперь нужно решить дуальную задачу: почему молча на сях сидеть сложнее, чем сидеть на сях и критиковать раст? :)

«Тварь ли я на сях сидящая или право на защиту своего болота имею».

I’ve come up with a set of rules that describe our reactions to technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you’re thirty-five is against the natural order of things.

Изучение нового языка программирования/технологии/фреймворка несет много сложностей и рисков.

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

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

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

Ситуация усугубляется еще тем, что большинство хороших _простых_ вещей уже давно было создано. Как пример, язык C#, старый, хороший и простой.

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

Раст это пример языка, который со стороны выглядит тупо и непривлекательно для тех, кто его не понимает на достойном уровне. Разрекламированные характеристики «memory safety + zero cost abstraction» ничего не говорят тем, кто сидит на managed языках типа Java/Python/Go.
Для тех, кто сидит на C/C++, memory safety это серьезный concern, но в одном лагере сидят люди, которые "yeah, just don’t write buggy code and you will have memory safety"/"stay away from C, you ***** donkey, and you will have memory safety«, в другом лагере сидят люди, которым бы хотелось memory safety, но у них не хватает знаний чтоб оценить какая именно memory safety идет под приправой Rust, и нет желания/мотивации в этом разбираться.

Я сам прошел через изучение раста, было примерно так:

1. Ок, использовать fn, чтоб определить функцию.
2. Ок, добавить mut к переменной, чтоб ее можно было изменять.
3. Box, Rc, Arc, RefCell, Cell, WTF? что это за хрень и нафига она нужна? Скип.
4. Borrow Checker, Lifetimes, это вообще какая-то ненужная хрень, скип.
5. Почему у каждого типа по стопицот генерик параметров, почему нельзя как в C#? Ок, можно все это закинуть в Box<dyn ...> и все будет работать? Но если заменить, то это тупо и лучше вообще раст не использовать? Сори, я ипал писать по стопицот генериков. Скип.
6. Почему я не могу из closure изменить значение локальной переменной? Ану погуглить... Через 3 часа в гугле — это ппц какой-то, в C# это тупо работало из коробки, что за хрень происходит в расте? Ага, вот щас закинем в RwLock<Arc<Rc<RefCell<Box<...>>>>, во вроде заработало.
7. И в чем смысл Раст? Столько понтов было, а в итоге ноль полезных фич, элементарные вещи делаются через жопу. Что? Мне надо еще раз вдумчиво перечитать книгу с третьей главы не скипая, и пройти отдельный курс по реализации double linked list, и самому реализовать Box/Rc/Arc/RefCell без подсказок, чтоб хоть что-то понять? Да ну фп***у, я на С могу сделать то же самое и мне не надо никаких книг читать.

На это я потратил несколько месяцев, пытаясь решить какая-то задачи в расте. Много людей забросит его прямо там.
Более менее нормально разобраться с растом я смог только когда забил на все задачи, отказался от идеи «learn while doing», серьезно засел за теорию и исходники.

Спасибо, что поделился.

Какую теорию и где читать порекомендуешь?

Стандартные книги найдешь сам, мне больше всего помгли продвинуться туториалы от www.youtube.com/...​/UC_iD0xppBwwsrM9DegC5cQQ, где он показывает как реализовать основные прмитивные типы Rust, там же уделяет хорошее внимание lifetime, генерикам и т.п.

Rust`у навіть немає в тому списку.

И за это стоить выпить!

C++ is now the fastest-growing programming language

гг. С++ в мінусах, С рулез, Руст вгору
developer-tech.com/...​irst-time-c-extends-lead

зараз Руст не 20 а 18
www.tiobe.com/tiobe-index

ты же понимаешь значение выражения «самый быстрорастущий», да?

Ему главное что-то негативное о C++ сказать, контекст неважен. Он этим с самого основания ДОУ здесь занимается.

Пару місяців тому С++ просів нехіло в індексі (був самий бистро падаюстчій, мінус 1.43).
developer-tech.com/...​irst-time-c-extends-lead
тепер в індексі виріс, і вуаля, самий самий бістро разтущій (+1.48)
www.techrepublic.com/...​ing-programming-language

Може, просто С++ ковбасить?

А Руст тим часом з 20го місця піднявся на 18 місце, потіснивши обжектів-це і Дарт.

Може, просто С++ ковбасить?

просто с++20 зарелизили. сейчас плюсы пойдут вгору

я теж так подумав, що ++20 причина:
як тільки хом"якки награються з новим С++20, піде відкат

С++ це як гривня, прийшов транш від МВФ — укрепляж, але довготривалий тренд на девал. Свою зірку С++ піймав в середині нульових.

Може.
А може такі коливання в принципі норма для мови, яка вже давно зайняла свою нішу і не завойовує нові сегменти ринку, проте все ще розвивається, проектів на ній існує багато, інколи з’являються нові, інколи дропаються старі і т.д. і т.п., а тобі просто в дитинстві наступив на ногу Страуструп ¯\_(ツ)_/¯

та ні, в тему про Руст набігли С++ники та почали: дивіться, в нас знову встає ... так у кого батхерт?

Ну мне, например, С++ не нравится, но лучше пока никто ничего не придумал.
И да С++ сложный язык программирования.
С простой, но что-то большое и сложное на нем писать — это жопа.

так для того і придуманий Rust, бо на С пісать сложноє «жопа», а на С++ за 21 день не получитьццо, D не взлетів, Nim — а шо єто.

Только вот он не как не тянет на замену ни С, ни С++.
Интересен был D, но так и не взлетел.

Руст взетів і уже закріпився в топ 20 тьобє,
з чього ти взяв, що не «тягне», якраз тягне,
єслі ти не про Ардуінки на 8 біт

Жабаскрипт во всех рейтингах еще выше. И что?
Во всем ембединге пока С и С++, в машинном леннинге тоже С и С++, на верхнем уровне в качестве клея Питон.
Всякие уебы и кровавые ентерпрайзы мне не интересны.

Во всем ембединге пока С и С++

www.bluefruit.co.uk/...​dy-for-embedded-software

в машинном леннинге тоже С и С++

www.arewelearningyet.com

Аналог OpenCV есть? Аналоги mxnet, darknet, tf, torch, caffe есть?
Можешь показать примеры написания модулей на расте для питона и матлаба?
Для CUDA примеры на расте тоже интересны?

И да требуется, чтобы работало это всё не медленнее того, что уже есть на С++.

Так по 10 кругу пошли. Вот я и повторил вопрос.
Там всё кончилось на opencv — его просто нет на расте. То, что там оным называют — это даже не смешно.
opencv саппортится интелом в большой степени и клали они на раст.

Почему нет? Это же нормально тут.

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

Для CUDA примеры на расте тоже интересны?

зачем CUDA если есть кошерный Vulkan

Compute Shaders — это далеко не совсем то, что дают OpenCL и CUDA.

а растаманам все равно

куду никогда толком не смотрел, вот интересно что там есть чего в компютах нету?

У Compute Shader маленький сторедж для расшеренной информации, все буфера и картинки так или иначе надо протаскивать через GPU, точность не высока, часто многие железки после 5-го знака после запятой уже дают большую погрешность (В OpenCL нужно явно задавать -cl-fast-relaxed-math опцию при компиляции чтобы получить пониженную точность). Очень тяжелые барьеры для завершения работы Compute Shader хорошь, но только когда знаешь как его использовать и чем это чревато. И это не для GPGPU вычислений.

У Compute Shader маленький сторедж для расшеренной информации

это какой? у меня на Vulkan maxComputeSharedMemorySize = 49152
и я не думаю что через CUDA этот параметр был бы значительно больше.

все буфера и картинки так или иначе надо протаскивать через GPU

можеш положить картинку в host visible memory всеравно ее контент так или иначе должен попасть на GPU чтобы там процесситца.

точность не высока

вроде в вулкане с точностью все строже чем на OpenGL

и я не думаю что через CUDA этот параметр был бы значительно больше.

А через OpenCL — 6Gb и доступ практически любой памяти.

можеш положить картинку в host visible memory всеравно ее контент так или иначе должен попасть на GPU чтобы там процесситца.

А если я физику считаю? Зачем мне протаскивать через GPU, то должно быть в домене процессора.

вроде в вулкане с точностью все строже чем на OpenGL

Например у Intel скорость relaxed math в 10-12 раз выше, чем той, что сертифицирована в IEEE-754. Так что врядли в вулкане используется не relaxed math, если же ты про highp/mediump — то там разница мизерная в производительности.

А через OpenCL — 6Gb и доступ практически любой памяти.

через VK_EXT_external_memory_host и VK_EXT_external_memory_dma_buf можно тоже много куда получить доступ, а maxComputeSharedMemorySize это память которая шарится между потоками одной рабочей группы, ее не может быть 6Gb.

Зачем мне протаскивать через GPU, то должно быть в домене процессора

логично что если GPU складывает числа то хотя бы раз но эти числа GPU прочитает с памяти. эта память может быть как host visible так и device local

Например у Intel скорость relaxed math в 10-12 раз выше, чем той, что сертифицирована в IEEE-754

беглый просмотр спеки говорит что есть специальный декоратор для этого
The RelaxedPrecision Decoration allows 32-bit integer and 32-bit floating-point operations to execute with a relaxed precision of somewhere between 16 and 32 bits.

через VK_EXT_external_memory_host и VK_EXT_external_memory_dma_buf можно тоже много куда получить доступ, а maxComputeSharedMemorySize это память которая шарится между потоками одной рабочей группы, ее не может быть 6Gb.

Почему не может? Это как раз и есть ограничение GPU, т.к. CS выполняются в её домене. В GPGPU домене такого, собственно нет, но за это платим скоростью.

логично что если GPU складывает числа то хотя бы раз но эти числа GPU прочитает с памяти. эта память может быть как host visible так и device local

Я не то имел в виду. Я имел в виду что доступ к буферам реализован через Standard Buffer Layout спецификацию и у многих GPU есть специальные методы доступа для таких буферов, плюс буфер проходит специальную подготовку, чтобы быть доступным из GPU. Когда используется в режиме GPGPU стандартов нет — протаскивай хоть слона.

беглый просмотр спеки говорит что есть специальный декоратор для этого
The RelaxedPrecision Decoration

Это хинт SPIR-V компилятора. Я проверял на nVidia и Intel — по умолчанию в Compute Shader идёт relaxed math под Vulkan и OpenGL. И сделать его не-relaxed часто нет никакой возможности, т.к. этот декоратор используется по умолчанию при конвертации SPIR-V в машинный код GPU процессора, в OpenCL и CUDA всё наоборот.

Почему не может? Это как раз и есть ограничение GPU, т.к. CS выполняются в её домене. В GPGPU домене такого, собственно нет, но за это платим скоростью.

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

плюс буфер проходит специальную подготовку, чтобы быть доступным из GPU

вот интересно а если я в host visible памяти выделил место под буфер, примапил его себе в процесс и невозбранно пишу в него а на GPU читаю, при этом даже не воткнув ни каких барьеров, когда в таком случае будет происходить та самая подготовка?

Это хинт SPIR-V компилятора. Я проверял на nVidia и Intel — по умолчанию в Compute Shader идёт relaxed math под Vulkan и OpenGL. И сделать его не-relaxed часто нет никакой возможности, т.к. этот декоратор используется по умолчанию при конвертации SPIR-V в машинный код GPU процессора, в OpenCL и CUDA всё наоборот.

на nvidia не проверял, там пишут что все что начиная с Compute Capability 2.0 оно IEEE 754, может конешно для вулкан какое то легаси включается непонятно только зачем.

Intel Ivy Bridge, первое поколение которое супортит vulkan 01.org/...​b_ihd_os_vol4_part3_0.pdf
вполне себе супортит
IEEE-754 requires floating point operations to produce a result that is the nearest representable
value to an infinitely precise result, known as «round to nearest even» (RTNE). 32-bit floating point
operations must produce a result that is within 0.5 Unit-Last-Place (0.5 ULP) of the infinitely precise
result. This applies to addition, subtraction, and multiplication

AMD
developer.amd.com/...​urces/RDNA_Shader_ISA.pdf
V_ADD_F32 Add two single-precision values. 0.5ULP precision, denormals are supported.
других вариантов тупо нету.

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

Если ты оформляешь их как константы или immediate данные, то в CS они идут как окружение шейдера и там действительно ограниченный доступ и память а-ля регистровая, т.е. по сути почти кешь по скорости, но если ты это делаешь в GPGPU домене, то данные передаются по другому, там нет GPU ограничений.

вот интересно а если я в host visible памяти выделил место под буфер, примапил его себе в процесс и невозбранно пишу в него а на GPU читаю, при этом даже не воткнув ни каких барьеров, когда в таком случае будет происходить та самая подготовка?

Например на Intel’овских платформах они пытаются завернуть твой юзер поинтер в адресное пространство GPU/GPGPU по страницам в MMU GPU перед использованием — операция не бесплатная. Если не получилось завернуть, то будет копирование — а это совсем дорого.

на nvidia не проверял, там пишут что все что начиная с Compute Capability 2.0 оно IEEE 754, может конешно для вулкан какое то легаси включается непонятно только зачем.

Так это для CUDA, я же выше говорил, что для CUDA и OpenCL IEEE-754 включено по умолчанию. В CS — нет.

Intel Ivy Bridge, первое поколение которое супортит vulkan 01.org/...​b_ihd_os_vol4_part3_0.pdf
вполне себе супортит

Оно суппортит это не для вулкана, а для OpenCL. В том документе, что ты привел, посмотри раздел 2.3 Floating Point Modes — там описан классический стандарт и альтернативный. Формат хранения в обоих случаях IEEE-754, вопрос что внутри и с какой точностью.

Я выше уже приводил пример — если на интел GPU включить IEEE-754 с точностью как в процессоре, то скорость упадёт от 10 раз. Для GPU это смерть — замедлитель никому не нужен, для GPGPU операций есть выбор, потому как могут быть разные требования.

но если ты это делаешь в GPGPU домене, то данные передаются по другому, там нет GPU ограничений

память GPGPU домене это та самая планка DDR воткнутая на материнке? ее вполне можно юзать в Vulkan
вот на моей системе показывает что можно целых 8Гб юзать.

Например на Intel’овских платформах они пытаются завернуть твой юзер поинтер в адресное пространство GPU/GPGPU по страницам в MMU GPU перед использованием — операция не бесплатная.

ок это все происходит при инициализации/бинде дескрипторов, и точно так же происходит в случае OpenCL

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

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

Оно суппортит это не для вулкана, а для OpenCL. В том документе, что ты привел, посмотри раздел 2.3 Floating Point Modes — там описан классический стандарт и альтернативный.

быстрый поиск по сорсам месы говорит что use_alt_mode проставляется только когда юзается ARB assembly это такое легаси что про него я вот только узнал.

а по AMD что?

память GPGPU домене это та самая планка DDR воткнутая на материнке? ее вполне можно юзать в Vulkan
вот на моей системе показывает что можно целых 8Гб юзать.

Не совсем — это может и системная память и локальная для GPGPU (видеопамять), пропущенные через MMU GPU/GPGPU.

ок это все происходит при инициализации/бинде дескрипторов, и точно так же происходит в случае OpenCL

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

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

Ну почему не может — смотри: www.khronos.org/...​ryHostPointerInfoEXT.html

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

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

Я не с головы это выдумываю — это из реализаций и Вулкан драйверов и OpenCL.

быстрый поиск по сорсам месы говорит что use_alt_mode проставляется только когда юзается ARB assembly это такое легаси что про него я вот только узнал.

То немножко другое — это альтернативный хэндлинг всяких корнер кейсов. Я говорил про это: software.intel.com/...​lower-math-precision.html Именно он по умолчанию работает во всех GPU шейдерах, включая CS. Ведь по большому счёту там большая точность не нужна, мы же не rocket science считаем. Поэтому использование CS для чего-то математически серьёзного нужно всегда рассматривать с долей скептицизма.

Если интересно, можем уйти в оффлайн, я могу дать код GLES2 шейдера для рейтресера, CS шейдера и CL кернела одного и того же алгоритма. Качество картинки везде одинаковая и скорость в среднем по палате тоже одинаковая, но только с выключенной в CL нормальной точностью для IEEE-754. Как только используешь CL в дефолтовом режиме — проседание в 10 раз минимум. Я тестил на всех промышленных GPU.

а по AMD что?

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

Если интересно, можем уйти в оффлайн

может лучше в отдельную тему? с удовольствием вас послушаю

Не совсем — это может и системная память и локальная для GPGPU (видеопамять), пропущенные через MMU GPU/GPGPU.

ну тоесть то что называют host visible, в вулкане ее много, по крайне мере на моей системе.

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

в Vulkan сброс кешей кроме одного случая всецело забота пользователя, я указал что барьеры не ставлю так что кеш не сбрасывается.

Ну почему не может — смотри: www.khronos.org/...​ryHostPointerInfoEXT.html

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

там же написано

Importing memory from a particular host pointer may not be possible due to additional platform-specific restrictions beyond the scope of this specification in which case the implementation must fail the memory import operation with the error code VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR.

тоесть если примапить через мму не удалось страдай как хочеш.

в блокирующем вызове, которая даст гарантию, что этот поток в приложении

даже если сбросили кеш Vulkan API не гарантирует что CPU не может изменить память в процессе того как GPU ее читает.

Поэтому использование CS для чего-то математически серьёзного нужно всегда рассматривать с долей скептицизма

а вот тут говорят что профит есть.
community.khronos.org/...​-faster-than-cufft/106192

Как только используешь CL в дефолтовом режиме — проседание в 10 раз минимум

возможно CL тормозная херня
вот тут ARM озаботился на тему точности
community.arm.com/...​in-mobile-gpus---part-iii
я еще не все эти шейдеры запустил у себя

ну тоесть то что называют host visible, в вулкане ее много, по крайне мере на моей системе.

Правильнее сказать будет host & GPU visible. Потому что на Интеле можно получить память, которую, например, host не будет видеть вообще. Её загружают blit операциями из host memory. Там удобно хранить константные данные.

в Vulkan сброс кешей кроме одного случая всецело забота пользователя, я указал что барьеры не ставлю так что кеш не сбрасывается.

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

тоесть если примапить через мму не удалось страдай как хочеш.

Я сказал к тому, что, например, на Интеле — это дефолтный способ выделения памяти, будешь ли ты её просто выделать стандартным API или как HOSTPTR — результат один и тот же.

даже если сбросили кеш Vulkan API не гарантирует что CPU не может изменить память в процессе того как GPU ее читает.

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

а вот тут говорят что профит есть.
community.khronos.org/...​-faster-than-cufft/106192

Я же говорю, что в плане производительности, профит огромный, в плане точности наоборот. Например, если мы работает с 8 или 16 битами цвета на канал — нам точности хватит с головой для обработки. Если же мы работаем с 24 или 32 битовым звуком, то представление 32 битогового числа в диапазоне 0..1 для FP уже будет неточным.

возможно CL тормозная херня

Мои эксперименты показывают что при правильно написанных драйверах и понимании что и для чего делается разница в производительности будет минимальная везде.

Потому что на Интеле можно получить память, которую, например, host не будет видеть вообще. Её загружают blit операциями из host memory. Там удобно хранить константные данные.

это называется просто VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT без флажка VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT

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

возможно в OpenGL в Vulkan такие приколы не одобряют, и вообще зря штоле в спеке есть целая глава
6. Synchronization and Cache Control
кстати она больше всего пугает новичков.

Я же говорю, что в плане производительности, профит огромный, в плане точности наоборот.

там профит не огромный а всего несколько процентов изза более эфективного использования памяти и кешей. да и если спека пишет что
Operations described as «correctly rounded» will return the infinitely precise result, x, rounded so as to be representable in floating-point. The rounding mode is not specified, unless the entry point is declared with the RoundingModeRTE or the RoundingModeRTZ execution mode.

Мои эксперименты показывают что при правильно написанных драйверах и понимании что и для чего делается разница в производительности будет минимальная везде.

не все драйвера одинаково полезны, у меня впечатление что финансирование драйверов OpenCL идет по остаточному принципу.

и вообще зря штоле в спеке есть целая глава 6. Synchronization and Cache Control
кстати она больше всего пугает новичков.

Там имеется в виду немного другой кеш, например render cache, на разных стадиях pipeline, который GPU пытается до последнего удержать в себе, чтобы при последующих операциях, просто перезаписать кеш, а не память. Например, у Intel S&F блок (strips and fans) пытается держать в себе примитивную модель 3D мира до последнего элемента в кеше, чтобы отсекать и разбивать частично невидимые треугольники. Я же говорил больше о процессорных кешах.

там профит не огромный а всего несколько процентов изза более эфективного использования памяти и кешей. да и если спека пишет что

Там код разный в cuFFT и в vkFFT — тяжело сопоставлять. Я для этого использую свой простенький рейтрейсер, который таскаю от платформы к платформе — на нём лучше всего видно. Если используется правильная точная математика, то проседание огромное в производительности.

А хтось в свій час рахував на CUDA рокет саєнс... пардон, страхові ризики.

Та й досі рахує.

rlsl — Rust-Like Shading Language
Нужно больше велосипедов

Поддержка растом OpenCL не так интересна как поддержка Rust’а в OpenCL. А это таки две большие разницы взросления языка. C99 и C++11 есть внутри OpenCL, а вот компиляции растовского кода в SPIR-V я что-то не видел нормального, многие поделки сдулись ещё пару лет назад. Последнее что я пробовал с пропатченным LLVM и CLANG для кодогенерации SPIR-V машинного кода было просто ужасно.

от нафига, мне зоопарка HLSL GLSL MSL хватает.

Это хотя бы стандартизировано, а компиляторы для Vulkan и OpenCL — нет. Например, берёшь компилятор от Imagination Technologies и от NXP — там такие серьёзные различия что код нужно писать чуть ли не в K&R стиле, чтобы на обоих платформах скомпилировалось, а у Intel’а на NEO софтварной платформе все плюшки компилятора, включая туеву хучу расширений. Бинарники SPIR-V с собой таскать ещё то наслаждение. Как быть уверенным, что скомпилированное одним компилятором и оптимизатором байт-код идеально ляжет под все платформы? Например, Intel использует векторную оптимизацию, которая на платформе без векторного процессора просто будет замедлителем, а не акселлератором. А таскать исходники ещё хуже — нужно проверять под всеми платформами, ибо OpenCL C ещё никогда не был настолько разным, как сейчас.

про OpenCL не скажу а под вулкан я видел только два компилятора, от кронос и внезапно от MS который компилирует DX12 HLSL в Spir-V

От MS — это тот, который опенсорсный? github.com/...​oft/DirectXShaderCompiler ? Они оба очень старые, оптимизация там очень слабая. Есть shaderc от гугля — он был по-лучше, т.к. заточен для embedded. Например, nVidia Vulkan принимает SPIR-V откомпилированный, но внутри у них довольно серьёзный инструмент, который фактически разбирает SPIR-V на кубики (дизассемблер) и заново компилирует в NVVM. Mesa3D компилятор последние два года очень на высоте, они туда очень много вложили труда (Intel в основном).

От MS — это тот, который опенсорсный? github.com/...​oft/DirectXShaderCompiler ? Они оба очень старые

новее нет, кстати spir-v туда гугль завез, чтобы разрабы под стадию и андроид юзали свои HLSL шейдеры, даже знаю один еще не вышедший ААА тайтл где собрались шейдеры им компилять в spir-v

Есть shaderc от гугля — он был по-лучше

оно о себе пишет
glslc wraps around core functionality in glslang and SPIRV-Tools
я вглубь не смотрел на раз они пишут что это врапер над кроносовским я склонен им верить.

nVidia Vulkan принимает SPIR-V откомпилированный, но внутри у них довольно серьёзный инструмент, который фактически разбирает SPIR-V на кубики (дизассемблер)

я думаю так и есть

оно о себе пишет
glslc wraps around core functionality in glslang and SPIRV-Tools
я вглубь не смотрел на раз они пишут что это врапер над кроносовским я склонен им верить.

SPIRV-Tools — это кодогенератор из LLVM IR в SPIR-V. По-ходу больше транслятор, вся соль в LLVM. Разница в кодогенерации LLVM 3.x и LLVM 10.x просто чудовищная. А многие проекты (те, что ты указал выше) используют древние LLVM.

ладно, посмотрим в глубь
shaderc не более чем один файл github.com/...​libshaderc/src/shaderc.cc
LLVMом там не пахнет

SPIRV-Tools

тут тоже не особо, это исходники утилит типа disasm и opt
возможно opt мог бы гнать spir-v -> llvm ir -> spir-v но нет, беглый просмотр показывает что он делает проходы собственоручно

тут тоже не особо, это исходники утилит типа disasm и opt

Сорри, я перепутал с SPIRVLib. И похоже, что да, shaderc испольщует только glslang. MS’овский же на дрейвнем LLVM.

Надо будет попробовать кроносовский компилятор, пишут, что он понимает C++11 и OpenCL. Но пока кроносовский софт меня сильно пугает, некоторые вещи плохо написаны, например, conformance tests для всех их стандартов, может компиляторами другая группа занимается.

при генерации HLSL-> spriv LLVM не участвует
github.com/...​piler/wiki/SPIR‐V-CodeGen
LLVM юзается для DXIL который вендо драйверы обязаны понимать

У них написано:

The starting point of the project is a fork of the LLVM and Clang projects, modified to accept HLSL and emit a validated container that can be consumed by GPU drivers.

Clang — это часть llvm-project.

Therefore, it is easier to go from frontend AST to SPIR-V than from DXIL since we do not need to rediscover certain information.

Translating frontend AST directly into SPIR-V binary precludes the usage of existing LLVM optimization passes. This is expected since there are also subtle semantics differences between SPIR-V and LLVM IR. Certain concepts in SPIR-V do not have direct corresponding representation in LLVM IR and there are no existing translation schemes handling the differences. Using vanilla LLVM optimization passes will likely violate the requirements of SPIR-V and results in invalid SPIR-V modules.

Instead, optimizations are available in the SPIRV-Tools project.

C++11 есть внутри OpenCL

Ура, наконец-то на опенцль можно формочки рисовать, джва года ждал!

Go уже закрепился в top4 и скоро попадет в top3, обогнав java.

ніт,
TIOBE Index for December 2020
показує що Іди спустився з 15 на 16,
Ржавий розіграв очко, а тупе Це луччє всєх і даже Жаби і Удава.

зі в гітхаб лідєр жабаскрипт

Rust был придуман, чтобы переманить часть сиприплюснутых, которые любят решать головоломки в C++ с undefined behaviour, implicit code paths и разбираться в 1000-строчных сообщениях об ошибках при использовании stl, boost или самодельных либ на шаблонах. Теперь им придется решать головоломки с borrow checker и zero cost abstractions в Rust. Также им не привыкать ждать по часу завершения компиляции проектов как на C++, так и на Rust.

Нормальные же программисты пишут простой и эффективнвй код на Go. См. dou.ua/forums/topic/16012

Сколько раз ты встречался с головоломками borrow checker Rust когда это не было связано с каким-то багом в твоем коде?

Я пишу на Go, поэтому головоломки borrow checker’а меня не затрагивают. А вот этим бедным людям приходится несладко из-за того, что они решили связаться с Rust — stackoverflow.com/...​ons/tagged/borrow-checker

Т.е. ты сам не знаешь про что пишешь? ок, продолжай.

те що на співбесідах цікавляться UB та іншими викрутасами, якими очікується, що володіють С++ жонглери не новина, але в масі будуть продожувати їсти кактус, замість того щоб розлслаблятися з Rust або Go.

А боров чекер не такий страшний,як його малють.
Достатньо розуміти мув семантику і концепцію володіння об"єктом.

А боров чекер не такий страшний,як його малють.
Достатньо розуміти мув семантику і концепцію володіння об"єктом.

UB тоже не такой страшный
достаточно владеть языком

скільки сторінок стандарту (якого саме 98, 03, 11, 14, 17) тре знати на пам"ять?

давненько видно по собєсам ходив

скільки сторінок стандарту

достаточно не делать ничего странного. типа руст изучать

С простой, но что-то большое и сложное на нем писать — это жопа

Именно поэтому ядро Linux из десятков миллионов строк написано но чистом C.

Вообще-то всем известно, почему там С. Потому что Торвальдс — он с молодости плотно привык к С и другого не приемлет. Был бы он не настолько консервативен — был бы там С++ (правда с жесткими ограничениями на многие фишки С++).

Линус несколько раз доходчиво объяснял, почему ядро линукс не написано на С++:

C++ is a horrible language. It’s made more horrible by the fact that a lot
of substandard programmers use it, to the point where it’s much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C

Цитата взята из harmful.cat-v.org/software/c /linus

C++ is a horrible language.

И что это, как не аналог того, что я написал выше, только другими словами?
Он просто не умеет в С++, не понимает и боится его. Всё.
Для меня же С++ очень приличный и удобный язык программирования. И да он требует многих усилий, чтобы научиться им пользоваться корректно.

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

У Линуса есть определённые мотивы в этом — то, что C++ мэйнстрим ориентируется на условия, которые могут быть недопустимы для ядра: исключения, тяжёлая стандартная библиотека со включением много чего непредсказуемого, слабоуправляемая политика в плане, какой код будет инлайниться, а какой — создавать отдельные блоки кода функций.

Это имеет место и для Windows, но в их специфику входит, например, что исключения делаются через SEH — очень дорого по сравнению с реализациями на таблицах (как делают почти везде GCC и Clang), но совместимо с собственными исключениями.

А ещё у C++ своё соображение о работе с памятью, которое выливается в ряд злобных граблей. Например, много лет в стандарте было сказано, что объект инициализируется, при динамическом выделении, оператором new. И никого это не волновало, пока буквально год назад не взорвалось на том, что какой-то компилятор решил, что malloc() не new и использование памяти после malloc() - UdB, на чём сделал левую оптимизацию. Сейчас срочно готовят правку, что malloc() с аналогами столь же полноправный помечатель памяти как корректно выделенной, как и new. Но затем следом потребуется то же для mmap() и кучи других аналогов... а теперь представь себе все эти хохмы в ядре.

Фактически, под ядро нужен очень специальный ограниченный диалект C++, в котором убрана куча возможностей, все завязки на них и т.д. — что-то близкое к C++ образца района 1993, только с добавкой пространств имён и некоторых других вкусностей более поздней разработки. Пока этого нет, проще оставаться на C.

правда с жесткими ограничениями на многие фишки
С++
Пока этого нет, проще оставаться на C.

Проще-ли. Не разумнее-ли сделать диалект С++ для ембединга.
С одной стороны это еще один язык. Но я бы даже в высокоуровневом на него перешел. С++ в странный области последнее время подался. Вот лично я для математики не использую почти ничего из стандарта старше 2003 года. Ну пару мелочей только, без которых запросто могу и обойтись.
Но вот те же умные указатели отличная вещь. Часть STL очень удобна.

По моему мнению главная ошибка тех, кто настаивает на С, попытка думать за других, что С проще и ошибок меньше сделают. Но это просто глупость — количество ошибок всегда пропорционально объему кода. И при большом объеме вся простота (меньший коэффициент ошибок) поглощается объемом кода и после толпа дружно и тупо борется с ошибками работы с памятью и бесконечно ловит их.

Да и за примером далеко ходить не нужно. Повызывай функции из BLAS, LAPACK, например, и не наделай ошибок с их 100500 параметров входных (и сократить то количество параметров нельзя). Посему или юзаешь чью-то обертку на классах или пишешь свою.
Для каждой нужно хзадасть stride, shape, по столбцам или по строкам и т.п. А если тензоры (матрицы с более чем двумя измерениями), то вообще пипец настает. И тут без ООП уже никак.

А пример шизы «си везде» есть идеальный GStreamer. Там дошли до того, что написали целую гигантскую ООП функциональность на С, которую сразу дает С++ и упрощает всё на порядок.

дивіться, в нас знову встає

У мене й не падав ;)

ага, упав на дуже бистро, а через місяць «бистро виріс»,
маніпулятивне твердженння

Тайтл: „C++ is now the fastest-growing programming language”
Ссылка: „.../c-is-now-the-fastest-growing-programming-language”

Top 10 anime betrayals of all time

пофиг. главное поднабросить. смотри, как флаймана колбасит — любо дорого посмотреть

так чьо там, Апплє переписать свій аплєкод на Руст... ну надо жє.. нікогда нє било і о5

Вот и посмотрим чем закончится оное для Огрызка.
Я предполагаю, что 90% что эксперимент закончится провалом.
10% что раст таки будет продвинут Огрызком.

а я навпаки, 90% що він, а 10% що фейл

Вот и увидим через пару лет.

Я предполагаю, что 90% что эксперимент закончится провалом.

Что именно будет причиной провала?

10% что раст таки будет продвинут Огрызком.

Вот когда Mozilla продвинет Rust, тогда и поговорим
Вот когда Dropbox продвинет Rust, тогда и поговорим
Вот когда Oracle продвинет Rust, тогда и поговорим
Вот когда Facebook продвинет Rust, тогда и поговорим
Вот когда Google продвинет Rust, тогда и поговорим
Вот когда Amazon продвинет Rust, тогда и поговорим

========== вы находитесь здесь ==========
Вот когда Apple продвинет раст, тогда и поговорим

Хорошо, я не против.

Что именно будет причиной провала?

Потому что типичная картинка «приходит студень на контору и говорит, что надо всё выкинуть и переписать». Если студня послушаются, то проекту или конторе кранты.

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

Ну и доверяй — это твой выбор. Лично я очень редко кому доверия, особенно в варианте «всё выкинуть и переписать».

10% что раст таки будет продвинут Огрызком.

Он займёт свою заслуженную нишу рядом с Objective C, SWIFT’ом и другими странными решениями Apple.

Апплє переписать свій аплєкод на Руст

ты бредишь. у них свифт есть

перечитай текст вакансії ще раз, шевеля губами

ты про ту вакансию, где они в серверной у себя чтото там переписывают?
ты заметил что там «small team»? для непонятливых и с рустом в мозгах перевожу — «мы попробуем, а если фигня выйдет, выкинем вас с вашим рустом нах»

почєму ви не любітє кошєк — ви просто нє умєєтє іх готовіть.

включил свою любимую фишку — генератор случайных фраз?

а єлсі в епла получітсо в смалл тім в сервєрной, то шо?

то всьо. руст завоюет мир и все сишники сделают себе сепукку

все сишники сделают себе сепукку

Нет, просто пересядут на раст :)

Я слідкую за подіями в Rust тематиці і якщо щось буде, то напишу в чат. Додавайтеся t.me/rust_ukraine

5 members, 3 online — что-то не густо

Просто раст слишком элитарен для использования в массовых масштабах

В соседних чатиках из нижнего коммента заметно больше. Но там не только Раст.

Подписаться на комментарии