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

Обсуждение статей и новостей сайта
Автор
Повідомлення
Scoffer
Member
Аватар користувача

Повідомлення

vmsolver: 22.07.2025 12:20Где в спецификации RISC-V запрещает решать проблему невыравненого доступа аппаратно?
Там де прямо не дозволяє. Проги, скомпілені під такий проц, стануть несумісними з іншими ріск-в процесорами.
vmsolver: 22.07.2025 12:20Ты выдумываешь проблему там, где её нет.
Піди розкажи це квалкому
https://web.archive.org/web/20240118192 ... /101741936
https://web.archive.org/web/20231010073 ... 101784675
а то у цієї ноунейм контори проблеми виникли, а у форумного експерта - ні)))
веб архів тому що на форумі ріскви квалком судячи з усього забанили і потерли топіки :lol: :lol: :lol:

Відправлено через 4 хвилини 33 секунди:
ARM в aarch64, до речі, теж відмовились від стиснутих команд з aarch32 по рівно тим же причинам, що зараз ниє квалком. Це складно, і, що головне, це енергонеефективно. Теж не шарять мабуть як треба іса складати. Не те що якісь діди в маразмі з ріскви.
vmsolver
Member
Аватар користувача

Повідомлення

Scoffer: 22.07.2025 12:43 Там де прямо не дозволяє. Проги, скомпілені під такий проц, стануть несумісними з іншими ріск-в процесорами.
Откуда возьмётся несовместимость? Инструкции никто не менял, разница лишь в возможностей ядер.
Scoffer: 22.07.2025 12:43 Піди розкажи це квалкому
а то у цієї ноунейм контори проблеми виникли, а у форумного експерта - ні)))
веб архів тому що на форумі ріскви квалком судячи з усього забанили і потерли топіки :lol: :lol: :lol:

Відправлено через 4 хвилини 33 секунди:
ARM в aarch64, до речі, теж відмовились від стиснутих команд з aarch32 по рівно тим же причинам, що зараз ниє квалком. Це складно, і, що головне, це енергонеефективно. Теж не шарять мабуть як треба іса складати. Не те що якісь діди в маразмі з ріскви.
Там другой контекст обсуждения, они ведут речь не в том, что 16-битные инструкции плохи, речь о том, что в больших системах они ничего дают, экономия не заметна, а их обработка имеет отдельную реализацию, которая в большой системе просто сидит сбоку, но может создавать проблему унифицированного подхода обработки инструкций, ведь им нужно пропускная способность, которой там много и экономить 2 байта смысла нет, и просто хотят выпилить из большой системы то что надо для малых. Тоже самое сделал ARM при переходе на 64 бита.

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

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

Во многих других случаях эти инструкции полезны.

з.ы. ничего они не потёрли, то ты зраду и заговоры сочиняешь
https://lists.riscv.org/g/tech-profiles/topic/101741936
https://lists.riscv.org/g/tech-profiles/topic/101784675
Scoffer
Member
Аватар користувача

Повідомлення

vmsolver: 22.07.2025 13:45Откуда возьмётся несовместимость? Инструкции никто не менял, разница лишь в возможностей ядер.
Звідти що в спекі прямо пишуть "обробляйте невирівняний доступ в програмному rmw циклі". Якщо проц вмітиме в невирівняний доступ, то в rmw циклі він працюватиме так само тормознуто як і той шо не вміє. Якщо прога думатиме шо проц вміє і не робитиме rmw цикли, то вона не працюватиме в принципі на процесорі, котрий не вміє. Перевіряти вміння? Так нема такого параметра в регістрі стану, ну і якщо введуть то це два бінарника замість одного. Як бонус - якщо прога на плюсах намагатиметься достукатись до двох суміжних невирівняних слів, то вона має всі шанси отримати невірні результати в rmw циклі, бо плюси (та і майже всі мови насправді) загалом не вміють розрулювати таку ситуацію просто компілятором. Треба переписувати код так щоб таких ситуацій ніколи не сталось. Або юзати атоміки що ще тормознутіше. На цьому погоріла дек альфа свого часу.
vmsolver: 22.07.2025 13:45Там другой контекст обсуждения
Ні, там в презенташках прямо кажуть шо 16-бітні інструкції погані і мають багато проблем. Цитую
Unaligned fetch is challenging to
design, verify
• Cache line, page crossing instructions
• Increased wire delay/muxing
• Leads to designs that are:
• more expensive (NRE)
• slower (extra pipe stages)
• buggy (see Intel Jump Code Conditional)

Performance benefit is modest
• Best case: 2-3% speedup
• Often: slowdown (net negative when
program fits in icache)
vmsolver: 22.07.2025 13:45з.ы. ничего они не потёрли, то ты зраду и заговоры сочиняешь
У мене на ці топіки пише Forbidden

Відправлено через 9 хвилин 19 секунд:
Тобто ці ідіоти з ріскви ввели підтримку невирівняних інструкцій і не ввели підтримку невирівняних даних. Всі нормальні процесори роблять з точністю до навпаки.
vmsolver
Member
Аватар користувача

Повідомлення

Scoffer: 22.07.2025 14:07
vmsolver: 22.07.2025 13:45Откуда возьмётся несовместимость? Инструкции никто не менял, разница лишь в возможностей ядер.
Звідти що в спекі прямо пишуть "обробляйте невирівняний доступ в програмному rmw циклі". Якщо проц вмітиме в невирівняний доступ, то в rmw циклі він працюватиме так само тормознуто як і той шо не вміє.
Программа обрабатывающая невыровненные данные в любом случае будет медленее работать, просто по определению. Если проц это аппаратно разруливает, то просто замедление будет не таким большим. Это одновременно и причина, почему не всегда это хотят решать аппаратно.
Scoffer: 22.07.2025 14:07Якщо прога думатиме шо проц вміє і не робитиме rmw цикли, то вона не працюватиме в принципі на процесорі, котрий не вміє. Перевіряти вміння?
Программы не думают, это просто поток инструкций, процессор просто их обработает, а если будет вызываться исключения на не выровненных данных, то в прерывании он всё равно их обработает. В итоге, всё работает и программа ничего о нюансах не "знает".
Scoffer: 22.07.2025 14:07Так нема такого параметра в регістрі стану, ну і якщо введуть то це два бінарника замість одного. Як бонус - якщо прога на плюсах намагатиметься достукатись до двох суміжних невирівняних слів, то вона має всі шанси отримати невірні результати, бо плюси (та і майже всі мови насправді) загалом не вміють розрулювати таку ситуацію просто компілятором.
Ты не понимаешь, если данные это структуры в памяти, то есть опции компилятору сказать как их выравнивать или не выравнивать, компилятор и линкер по-умолчанию про эти дела знает, они же не вчера родились. Это тоже возможная причина, почему не хотят решить это аппаратно, сэкономить на том, что и так имеет решение. Просто, программист написавший программу с не выровненными данными её просто не отладит или компилятор сам добавит поля для выравнивания.
Scoffer: 22.07.2025 14:07 Ні, там в презенташках прямо кажуть шо 16-бітні інструкції погані і мають багато проблем. Цитую
• Best case: 2-3% speedup
В малых система прирост и до 15%, а в больших, как я выше и сказал, смысла нет, 2-3% это не прирост, если вспомнить, память на 64-битных системах и так расходуется больше чем на 32 битных, а по сравнению с 16 бит тем более. Вот поэтому там и обсуждали, что давайте с наших космических кораблей выпилим буржуйку, не нужна она более.

Відправлено через 1 хвилину 49 секунд:
Scoffer: 22.07.2025 14:16Тобто ці ідіоти з ріскви ввели підтримку невирівняних інструкцій і не ввели підтримку невирівняних даних. Всі нормальні процесори роблять з точністю до навпаки.
Ты ничего не понял.
Scoffer
Member
Аватар користувача

Повідомлення

vmsolver: 22.07.2025 14:23Ты не понимаешь, если данные это структуры в памяти, то есть опции компилятору сказать как их выравнивать или не выравнивать, компилятор и линкер по-умолчанию про эти дела знает, они же не вчера родились. Это тоже возможная причина, почему не хотят решить это аппаратно, сэкономить на том, что и так имеет решение. Просто, программист написавший программу с не выровненными данными её просто не отладит или компилятор сам добавит поля для выравнивания.
Ні, це ти не розумієш. Дані це не тільки те що йде в комплекті з прогою чи якісь там стеки, це ще вхідні дані звідкись там. З інтернетику наприклад. Котрий мало того що поголовно утф-8, так ще й біг-ендіанес. Щоб розпарсити веб-сторінку просто необхідно мати швидкі методи роботи з невирівняними даними. Якщо ти візьмеш історичну хронологію, то ні арм, ні міпс, ні спарк, ні павер спочатку не вміли з ними працювати, в 80х. А потім всі почали вміти в подальших версіях, в 90х. І лише рісква в 2025му робить вигляд шо їх не існує.
vmsolver: 22.07.2025 14:23 если будет вызываться исключения на не выровненных данных, то в прерывании он всё равно их обработает
Зараз так вимушено іноді роблять, але спека цього не рекомендує тому що і без того тормозний доступ на процесорі без підтримки вирівнювання стає ще більш тормозним. Спека прямо пише, робіть рмв в лоб на всі випадки життя. Всі претензії туди.

Відправлено через 2 хвилини 39 секунд:
vmsolver: 22.07.2025 14:23Вот поэтому там и обсуждали, что давайте с наших космических кораблей выпилим буржуйку, не нужна она более.
Ні, вони хотять випилити не тому що не потрібна, а тому що ЗАВАЖАЄ. В тому ж х86 теж багато непотребу, але його чомусь не випилюють за відсутністю необхідності.
vmsolver
Member
Аватар користувача

Повідомлення

Scoffer: 22.07.2025 14:44 Ні, це ти не розумієш. Дані це не тільки те що йде в комплекті з прогою чи якісь там стеки, це ще вхідні дані звідкись там. З інтернетику наприклад. Котрий мало того що поголовно утф-8, так ще й біг-ендіанес.
Читают по байту и потом собирают из них нужное значение, вот и вся проблема.
Текст в utf-8 имеет сложный формат данных, там без последовательной обработки не обработаешь. К тому же, все служебные символы однобайтовые как и английские буквы.
Размеры текстов не такие чтобы загрузить современные процессоры.
Ты преувеличиваешь.
Scoffer: 22.07.2025 14:44 Щоб розпарсити веб-сторінку просто необхідно мати швидкі методи роботи з невирівняними даними. Якщо ти візьмеш історичну хронологію, то ні арм, ні міпс, ні спарк, ні павер спочатку не вміли з ними працювати, в 80х. А потім всі почали вміти в подальших версіях, в 90х. І лише рісква в 2025му робить вигляд шо їх не існує.
Ничего страшного, по байтику всё разбирается. Собственно, ситуации, когда ты точно знаешь что следующие 4 байта это число не так и часты, как правило ты не знаешь что дальше.
Scoffer: 22.07.2025 14:44
vmsolver: 22.07.2025 14:23 если будет вызываться исключения на не выровненных данных, то в прерывании он всё равно их обработает
Зараз так вимушено іноді роблять, але спека цього не рекомендує тому що і без того тормозний доступ на процесорі без підтримки вирівнювання стає ще більш тормозним. Спека прямо пише, робіть рмв в лоб на всі випадки життя. Всі претензії туди.
Оно по байту десериализуется влёт просто. Ты представляешь сколько данных так можно десериализовать просто за время доступа к случайным данным в ОЗУ? Доступ в L1 4 такта и ОоО машинка страшно набросится на всю эту легкотню.

Текст без аппаратного доступа к невыровненным данным у него не парсится :facepalm:

Відправлено через 2 хвилини 55 секунд:
Scoffer: 22.07.2025 14:47Ні, вони хотять випилити не тому що не потрібна, а тому що ЗАВАЖАЄ. В тому ж х86 теж багато непотребу, але його чомусь не випилюють за відсутністю необхідності.
Это одно и тоже, в больших системах они не решает проблемы, а создают. АРМы это уже прошли, всё ок.
Scoffer
Member
Аватар користувача

Повідомлення

vmsolver
Не збирає ніхто нічого зараз по байтику, це повільно. Всі юзають SIMD, з котрим у ріскви ще окрема історія. Той же хром вимагає SSE3, в котрому вперше з'явилась LDDQU - завантаження 128-біт не вирівняних даних із пам'яті. А значить що? Вірно, всі проблеми з невирівняним доступом залишаються і множаться ще й на підтримку зі сторони векторних інструкцій.

Відправлено через 12 хвилин 32 секунди:
До речі про вектори. Спочатку арм, а потім слідом рісква зробили помилку в виборі технології. На вектор плаваючого розміру погано вкладаються існуючі алгоритми паралелізації обробки даних. Як результат на армі апле і квалком відверто забили на све2 на користь старого фіксованого неону, не підтримується све2 і зі сторони мобільних ОС, ну а на ріскву просто забили :D
vmsolver
Member
Аватар користувача

Повідомлення

Scoffer: 22.07.2025 15:13 Не збирає ніхто нічого зараз по байтику, це повільно. Всі юзають SIMD, з котрим у ріскви ще окрема історія. Той же хром вимагає SSE3, в котрому вперше з'явилась LDDQU - завантаження 128-біт не вирівняних даних із пам'яті. А значить що? Вірно, всі проблеми з невирівняним доступом залишаються і множаться ще й на підтримку зі сторони векторних інструкцій.
SIMD ему не для парсинга текстов надо, знаешь ли кроме текстов есть картинки, видео и т.д. Данные просто так невыровненными из ниоткуда не появляются если что.
Короче говоря, у тебя всё время тема смещается в сторону, во время ищешь трудности на ровном месте, в то время как они решаются без особых проблем и проблемами особо не являются, некоторые из них представляют просто инженерную задачу.

з.ы. Выхожу из этого чата, надоело.
Scoffer
Member
Аватар користувача

Повідомлення

vmsolver: 22.07.2025 15:27Данные просто так невыровненными из ниоткуда не появляются если что.
Маячня. Більшість тексту на планеті - невирівняні дані. Більшість відео - невирівняні дані. Все що потиснуто всякими архіваторами і компресорами - невирівняні дані. Мережевий трафік - невирівняні дані.
Це вирівняних можна перелічити на двох пальцях.
yuriy_dd
Member

Повідомлення

Scoffer: 22.07.2025 10:30Можна, але якою ціною?
гарно написано, у RISC-V - все ще гірше ніж я думав

Відправлено через 6 хвилин 58 секунд:
Scoffer: 22.07.2025 15:26Не збирає ніхто нічого зараз по байтику, це повільно. Всі юзають SIMD
є купа почарної обробки навіть в glibc, хромі і тд

якщо з памяті читаєш 1 байт, фактично читається більше, і коли звернешся за наступним - він повернеться з кешу

доводиться дуже часто обробляти почарно - xml, json
Scoffer
Member
Аватар користувача

Повідомлення

yuriy_dd
Читати по одному байту це повільно і погана практика. З кешу теж читається не один байт, а 64-128-256 байт в залежності від архітектури. Glibc мультиплатформа і має працювати на будь-якому чайнику, навіть тому, котрий про кеш нічого не знає, а хром в хвіст і гриву юзає векторні інструкції.
Ще гірше по одному байту писати. В залежності від архітектури і мікроархітектури це може викликати рмв цикли на мікрокомандному чи програмному рівні. Так добра половина армопроцесорів мають реальне квантування доступу на рівні 32-64 біт, і в разі запису байта генерують внутрішній рмв цикл. Тобто зчитають з кешу 64 біти, змінять в них 8, і запишуть назад 64 біти. :horror: Це працює, але це довго.
Востаннє редагувалось 22.07.2025 16:22 користувачем Scoffer, всього редагувалось 2 разів.
vmsolver
Member
Аватар користувача

Повідомлення

Scoffer: 22.07.2025 15:30
vmsolver: 22.07.2025 15:27Данные просто так невыровненными из ниоткуда не появляются если что.
Маячня. Більшість тексту на планеті - невирівняні дані. Більшість відео - невирівняні дані. Все що потиснуто всякими архіваторами і компресорами - невирівняні дані. Мережевий трафік - невирівняні дані.
Це вирівняних можна перелічити на двох пальцях.
Хватит уже чушь нести. Это всё последовательные форматы, которые надо обрабатывать, их выравнивание мало на что влияет, а результаты парсинга выровнены и последующая обработка имеет с выровненными данными. Выдумываешь проблемы на ровном месте.

Відправлено через 1 хвилину 36 секунд:
yuriy_dd: 22.07.2025 16:00якщо з памяті читаєш 1 байт, фактично читається більше, і коли звернешся за наступним - він повернеться з кешу
С памяти вообще по 64 байта всё читается, это он думает, что по байту это значит из памяти читать по байту, нет можно читать сразу по 8 байт в регистр, а потом обрабатывать по одному, из кеша 8 байт вылетает аж бегом. Техник много, если мозги есть.
Scoffer
Member
Аватар користувача

Повідомлення

vmsolver: 22.07.2025 16:22 это он думает, что по байту это значит из памяти читать по байту
Що за бредятина? По-перше я чудово знаю як проц читає дані з пам'яті, по-друге до тебе не доходить що для того щоб витягнути невирівняне слово треба від 22 до 46 команд ріск-в, лінки на те що генерує компілятор на попередній сторінці. А компілятор не дурень, просто архітектура така калічна. х86 і арм64 обходяться в 1 і 2 команди в залежності від ендіанес.

Відправлено через 4 хвилини 59 секунд:
На х86 в останніх авх є навіть команда завантаження з різними порядками, тобто 1 і 1 команди виходить. Одна замість 46, ага.

Відправлено через 9 хвилин 35 секунд:

Код: Виділити все

#[no_mangle]
pub fn read_u32(buf: &[u8; 8]) -> u64 {
    u64::from_be_bytes(*buf)
}
--target aarch64-unknown-linux-gnu -C opt-level=3

Код: Виділити все

read_u32:
        ldr     x8, [x0]
        rev     x0, x8
        ret
--target x86_64-unknown-linux-gnu -C opt-level=3

Код: Виділити все

read_u32:
        mov     rax, qword ptr [rdi]
        bswap   rax
        ret
--target riscv64gc-unknown-linux-gnu -C opt-level=3

Код: Виділити все

read_u32:
        lbu     a7, 0(a0)
        lbu     a6, 1(a0)
        lbu     a3, 2(a0)
        lbu     a4, 3(a0)
        lbu     a5, 4(a0)
        lbu     a2, 5(a0)
        lbu     a1, 6(a0)
        lbu     a0, 7(a0)
        lui     t0, 4080
        slli    a3, a3, 16
        slli    a4, a4, 24
        or      t1, a4, a3
        li      a4, 255
        slli    a2, a2, 8
        or      a2, a2, a5
        slli    a5, a1, 16
        slli    a0, a0, 24
        or      a0, a0, a5
        lui     a5, 16
        slli    t2, a4, 24
        addi    a5, a5, -256
        slli    a6, a6, 8
        slli    a1, a1, 8
        or      a3, a6, a7
        slli    a7, a7, 56
        or      a3, t1, a3
        or      a0, a0, a2
        slli    a2, a0, 32
        srliw   a0, a0, 24
        and     a5, a5, a3
        or      a2, a2, a3
        or      a0, a0, a1
        slli    a5, a5, 40
        srli    a1, a2, 24
        srli    a3, a2, 8
        srliw   a4, a2, 24
        and     a2, a2, t0
        or      a5, a7, a5
        and     a1, a1, t0
        and     a3, a3, t2
        slli    a4, a4, 32
        slli    a2, a2, 24
        or      a1, a1, a3
        or      a2, a2, a4
        or      a0, a0, a1
        or      a2, a2, a5
        or      a0, a0, a2
        ret
І так тупо всюди. Куди не плюнь, на ріск-5 всюди якась лажа. Прямо ідеальний приклад як робити не треба.

Відправлено через 14 хвилин 11 секунд:
--target powerpc64le-unknown-linux-gnu -C opt-level=3

Код: Виділити все

read_u32:
        ldbrx 3, 0, 3
        blr
Рекордсмен. 1 команда штатно без додаткових розширень. Бо IBM це вам не :censoured: собачий. Там про щось думали коли створювали ISA.
yuriy_dd
Member

Повідомлення

Scoffer: 22.07.2025 16:17а хром в хвіст і гриву юзає векторні інструкції
я бачу купу почарного коду:
https://github.com/v8/v8/blob/main/src/ ... -parser.cc
Scoffer: 22.07.2025 16:17Ще гірше по одному байту писати
а я наприклад дуже часто пишу в файл через mmap і побайтно - різні бінарні структури записую
vmsolver: 22.07.2025 16:22нет можно читать сразу по 8 байт в регистр, а потом обрабатывать по одному
дуже ускладнюється код (і щоб потім оновлювати), легко можуть знадобитись байти з наступного 8-ми байного регістру
vmsolver
Member
Аватар користувача

Повідомлення

Scoffer: 22.07.2025 16:57 А компілятор не дурень, просто архітектура така калічна. х86 і арм64 обходяться в 1 і 2 команди в залежності від ендіанес.

І так тупо всюди. Куди не плюнь, на ріск-5 всюди якась лажа. Прямо ідеальний приклад як робити не треба.
Что тебе мешает понять, что в архитектуре RISC-V нет ограничений на невыровненный доступ? Это всегда есть особенность конкретных реализаций ядер. Инструкция чтения просто говорит, дай мне слово по такому-то адресу, далее железо подхватывает эти данные и делает свою магию.

И главное, в теме RISC-V от Nvidia, в их ядрах тоже есть проблема невыровненного доступа?

Відправлено через 4 хвилини 7 секунд:
yuriy_dd: 22.07.2025 17:15дуже ускладнюється код (і щоб потім оновлювати), легко можуть знадобитись байти з наступного 8-ми байного регістру
То что это усложнение - конечно же, смысл был показать, что есть много разных техник, а какие из них выбирать конечно зависит от задачи.
Scoffer
Member
Аватар користувача

Повідомлення

vmsolver
Мені заважає те що компілятор робить на практиці. Так от вище згенерений код буде однаково повільно працювати незалежно від того вміє конкретно взята мікроархітектура чи ні. Тому що треба спеку внятно писати. Чи ти думаєш що компілятори ідіоти пишуть і не розуміють як треба насправді компілити?
vmsolver
Member
Аватар користувача

Повідомлення

Scoffer
Под другую реализацию в любом случае нужна перекомпиляция. Но и без неё в целом работать будет, но не так быстро.
Где в спеках и архитектуре запрещен unaligned access?
Ну и что там у Nvidia?
Scoffer
Member
Аватар користувача

Повідомлення

vmsolver
Якщо під кожну реалізацію треба окремо компілити то гівно це а не стандарт.
В спеках написано що невирівняний доступ може бути екстримально повільним, нам пофіг, живіть з цим як хочете (ц)
Що там у нвідії питання максимально дивне враховуючи, що у нвідії поки що немає нічого. Залізо де? На сторонніх процах ото буде якраз те що компілить загальний компілятор, вони не будуть постачати бінарники куди під кожну сторонню реалізацію в світі.
yuriy_dd
Member

Повідомлення

Scoffer: 22.07.2025 16:57pub fn read_u32(buf: &[u8; 8]) -> u64
а це ви так спеціально назву даєте u32, хоч повертає u64 - щоб когось запутати?
Scoffer
Member
Аватар користувача

Повідомлення

yuriy_dd
Це не до мене, я просто взяв рандомний приклад з інету і запустив його на 4х архітектурах з однаковими параметрами компілятора.
Дозволяю переписати і перейменувати як хочеться :D
Відповісти