Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

Rust сообщество

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

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.

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

Горілки!

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 — тяжело сопоставлять. Я для этого использую свой простенький рейтрейсер, который таскаю от платформы к платформе — на нём лучше всего видно. Если используется правильная точная математика, то проседание огромное в производительности.

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

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

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

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

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

Тайтл: „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 — что-то не густо

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

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

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