Comments 6
Ну так в чём причина такой низкой производительности на RISC-V ? В каких единицах проводилось измерение ? В абсолютных или в нормированных ? Использовалось ли векторное расширение ? Где анализ кода ?
PS: При N>1000 ваша задача просто не помещается в 1МБ кэш микропроцессора C910.
Эта реализация была написана под Lichee Pi, у которого 128-битный векторный регистр. Мною же была сделана оптимизация этой функции под Banana Pi c 256-битным векторным регистром.
Т.е. идея масштабируемых векторных расширений, когда один бинарник может автоматически задействовать любую ширину регистра, не работает даже на gemm?
Анализ кода не проведен, совершенно не понятно чего они там накодили и как. И что может означать вот это выражение "адаптация под 256-битный векторный регистр" ? RVV не требует никакой адаптации под длину регистра.
Так на x86_64 OpenBlas получает производительность примерно 80-90 % от теоретического максимума процессора. А на Risc-v примерно 20-25%
Может кто-нибудь подскажет новичку в этом вопросе как считать эти цифры. Пример с матрицами 32х32. На исходном коде я получил 238000 тактов. С интринсиками код у меня не скомпилировался - чего-то в инструменте не хватает. Но я нашел gemm на ассемблере с векторным расширением. Под регистр 128 бит. Получилось 25000 тактов. Процессор делает 2 мака с float за такт. Итого 4 операции. Всего сложений и умножений 32*32 * (32+32-1)= 64512. Итого теоретический максимум 64512/4 = 16128? Результат 25000 составит 64% от максимума . Верно? Или все не так?
Две проблемы BLAS/gemm на RISC-V