NVIDIA забезпечить підтримку CUDA на системах із процесорами RISC‑V

[oleg5d75]

Архітектурі RISC-V вже 15 років не кажучи вже про саму RISC а віз і нині там, мені здається що сам проект RISC-V з самого початку напів мертвонароджений, багато хто з ним носиться але результатів у масовому застосуванні майже нуль

[AssayMAS]

Ще гірше по одному байту писати. В залежності від архітектури і мікроархітектури це може викликати рмв цикли на мікрокомандному чи програмному рівні.

когда я пишу или читаю по байту то компилятор сам устанавливает сколько то кэша на файло обмен и я работаю с ним... а когда кэш переполнится то идёт уже обращение к ОС "узакониванию". Компилятор позволяет в широких диапазонах кэш настраивать 1-100КБ до тревожинья ОС.

Чи ти думаєш що компілятори ідіоти пишуть і не розуміють як треба насправді компілити?

ну не знаю как у вас, но парочку листов галок у компиляторы видел что исполняемый файл в зависимости от того как проставить галки может с 20КБ до 0,1МБ вырасти... а по сути внутри исполняемого файла под ММХ, SEE, и чистый x86 - как и забить на безопасность DEP, и разные особенности ОС от вин ХР до 11.

[Scoffer]

AssayMAS
До чого тут файлообмін? Коли ти пишеш один байт в кеш, то процесор виділяє строку кешу в 64 (в випадку х86 і більшості армів) байти, блокує її, і пише твій байт. Але на фізичному рівні це означає що треба як мінімум продублювати біт парності на кожен байт, а з ЕСС не біт а всі чотири біти. Що для деяких процесорів тупо дорого, мікроконтролерів там всяких наприклад, чи ультранизькопаверних провесорів. Тому вони беруть строку кешу в 64 байти, блокують, читають з неї 64 біти(8 байт), змінюють один твій байт, записують 64 біти назад, що дозволяє зекономити біти на контролі парності/есс. І так для кожного байта. В порівнянні з записом 64 бітів одним махом це навіть не в 8 раз повільніше виходить, а може бути що й в усі 80. За будь-якої можливості слід уникати побайтової роботи з пам'ятю. Це повільно в будь-якому випадку, але в деяких процесорах повільно прям на рівні елітного слоупока.

Відправлено через 14 хвилин 33 секунди:
За великим рахунком з сучасних мов програмування варто б випилити всі типи, менші за 64 біти, а в разі необхідності обробки окремих байтів робити це маскуванням, благо в simd зараз поназавозили всякого цікавого. Просто в зв'язку зі слабкою сумісністю з реальним апаратним забезпеченням. Часи коли проц фізично тягнув з пам'яті байт дааааавно закінчились.

[AssayMAS]

але в деяких процесорах повільно прям на рівні елітного слоупока.

так чтетие\запись это не проблема ОС? Как там в книжечке для детей - БИОС и ОС выравнивают неоднородности железа что бы программы могли ... .
Если компилятор "не очень" то будет медленно читать писать по байтово - но это ж костыль оставили для совместимости.
А у меня "using a memory block may also be a good idea" "The default buffer size is 4096 bytes per file"
то есть я по байтово в коде читаю - а в реале из 4К что в кэше (озу\Л3\л2\л1). А на проце в зависимости от архитектуры всё сильно при сильно по разному будет. Процы то не "х86" давно - это они тоже в целях совместимости во внешний мир проецируют.

За великим рахунком з сучасних мов програмування варто б випилити всі типи, менші за 64 біти

так Supported types: Byte (8-bit), Word (16-bit), Long (32-bit), Quad (64-bit), Float (32-bit), Double (64-bit) and Characters оставили в целях совместимости.
И если ручками тип не указывать - то будет 64 бита. А если переключить пару галок в компиляторе то "х86" и 32бита...
Как компилятор научат так и будет.

[Scoffer]

AssayMAS
Ти плутаєш роботу з ФС і роботу з оперативою.

[AFU_power]

Ха-ха-ха, коментарі провалили IQ тест на RISC V, або негатив, або думають, що вона така сама як 15 років тому і не розвивалась.

[vmsolver]

Коли ти пишеш один байт в кеш

Прекращай эти глупости, ты в кеш ничего не пишешь, программа читает байт в первый раз, проц не находит его в кеше L1, кидает запрос в ОЗУ и в ответ прилетает как минимум 64 байта твоего текста, которые отныне доступны за 4 такта для чтения и записи, как будто они в ОЗУ, если проц видит что у тебя цикл то предварительное кеширование загрузит нормальную порцию текста в кеш, который проц быстро обработает и только потом результат отправится в ОЗУ. Никто промежуточные результаты вычислений в ОЗУ не отправляет, даже если в программе написано, что надо сохранить какое-то значение в переменной, она просто закешируется и запись будет когда программа начнёт вычислять что-то другое, тогда освободится кеш и та закешированная переменная будет записана в ОЗУ, а кеш-линия освобождена для следующих данных.

ЕСС памяти тут вообще не приделах, контроллер памяти работает с кеш-линией как с одним куском, новое значение посчитает перед отправкой в ОЗУ. В кешах своя система проверки целостности данных.

[Scoffer]

vmsolver
Ознайомся з принципом роботи кеш-ліній і чому свого часу dec alpha принципово не мала на рівні ISA роботи з байтами, що це їм дало, і які наслідки викликало. А потім побалакаємо.

[vmsolver]

Scoffer
Лучше ты почитай как это работает.

[Scoffer]

vmsolver
Я якраз читав, а ти схоже що або не читав зовсім, або догори дриґом.
Кеш-лінія це не одна нерозривна сутність. Це всього-навсього нн-а кількість байтів, об'єднаних спільними тегами доступу і когерентності. І всьо. Проц може і в реальності зчитує хоч один байт з неї за раз, хоч всі 64. Деякий з процесорів точніше. А деякий не може зчитати байт, і, що головніше, не може записати один байт в кеш-лінію, а таких добра половина армів якщо що. Тому цей проц, котрий не може, займається жонглюванням з внутрішніми RMW циклами. А це ПОВІЛЬНО.

Відправлено через 4 хвилини 23 секунди:
Кожен, назвемо це квантом доступу, кеш-лінії має як мінімум свою перевірку на парність, а в випадку есс, ще й свою есс. Якщо квантом є байт, то есс на кожен байт окремо, ага. Звідси бажання зекономити на зайвих бітах і RMW. Бо це практично в півтори рази менше транзисторів на той же об'єм кешу на рівному місці.

Відправлено через 5 хвилин 3 секунди:
Не кажучи вже про те, що зчитати 8 байт одним махом і розпотрошити їх в регістрах процесора в будь-якому випадку швидше ніж читати по одному. І писати по одному. Тому будь-яка сучасна прога, котра претендує на швидкість роботи, взагалі не має мати справу ні з якими чарами. Краще вектори, гірше скалярне маскування, але все одно це швидше ніж чари. Така от реальність.

[vmsolver]

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

Ты по сути рассматриваешь работу без кеша, а говоришь про проблемы с кешем. Проблема с твоей стороны, а не у кеша или процессора.

Поэтому прекращай эти свои глупости.

[Scoffer]

vmsolver
Ти верзеш маячню. Перечитай що я вище написав стільки раз поки не дійде як працює кеш-лінія. Це без кешу не було б ніяких проблем, а з кешем треба враховувати нюанси. ООО тут взагалі ні до чого, це стосується абсолютно всіх процесорів з кешем. А інтел 286 не стосується, йому і з байтами все нормуль.

[AssayMAS]

Ти плутаєш роботу з ФС і роботу з оперативою.

а как с файловой системой работать без кэша в оперативе? Если строго без кэша из ОЗУ в ПО, но тогда ОС кэш сделает. Там разница в кэше ручками в коде и кэш в ОС вин10 на моём ПК 10-20% по МБ в сек... что на фоне сотни ни о чём...
А когда в коде на х86 х64 я озу по байтово читаю\пишу - то проц и его алгоритмы для л1 л2 л3 кэшуруют все без моего участия... разве что 1 раз обнова биоса +5% попугаев накинула.
И что 1 байт читаю пишу что 100 байт скорость не сильно отличается так как кэшируется процом без моего участия несколько КБ.

А інтел 286 не стосується, йому і з байтами все нормуль.

там у 2х86 сделали работу с ОЗУ по сравнению с 80х86 без простоя и как написано в книги "микропроцессоры" 181 страница пока 8086 3 байта обработает то 1810вм86(2х86) 5 байт на той же частоте. Плюс у 2х86 кэша (конвейера команд) аж на 6 команд (16бит по 6 = 12байт). Но с точки зрения программиста оно само как то работает без его вмешательства.
А если как ты требуешь вмешиваться ради понта попугаев глубоко в работу процессора, то теряешь универсальность и совместимость. Вот я сча на виртуалке могу любой код с 2х86 запустить и будет работать на тысяче видов разных процессоров - да медленно но работать. А если какой то ПО заточить под конкретный проц то потеряешь совместимость.