В принципе все реализации (без обёрток под ЯП) тут описаны
Эталонная реализация (сайт не доступен в РФ - блокируют с той стороны) вполне нормально сделана для числодробильной библиотеки на смеси си и фортрана. Там в приоритете не красивый код, а скорость работы если что. Потому как поверх blas-а много всякого говна крутится, вроде того же numpy.
Ты хотел просто переписать 1 в 1? Если нет, то зачем тебе что то кроме pdf с описанием функций, и эталонной неоптимизированной реализации для подсказок?
Имхо, проще всего ковырнуть какую-нибудь относительно свежую реализацию, например под OpenCL. Там вполне понятно все даже обезьяну и там же должен быть их бенчмарк на питоне с комментариями.
Но я бы порекомендовал оставить BLAS в покое и браться двумя руками за Blis.
Но я бы порекомендовал оставить BLAS в покое и браться двумя руками за Blis.
почудилось Blitz, Blitz++ которые разве что чуть моложе BLAS :-)
а вообще от подобного софта не требуется красоты. Стабильный, точный, проверенный, на любой платформе одинаков.
все-же прекрасно понимают, что любое BLAS-like хуже оригинала. И брать страшно. Кто хочет первым наступить на грабли ? красивые, с вензелёчками и с полиморфизмом грабли
а вот в бласе все грабли за много лет растоптаны. Как-бы стандарт lapack,blas старые страшные, но без граблей. Важен результат берёшь их, важен процесс - терзаешь новодел
все-же прекрасно понимают, что любое BLAS-like хуже оригинала
Нет. Отучайтесь говорить за всех. В некоторых инструкциях BLIS быстрее того же OpenBLAS, замеры производительности на разных процах это наглядно показывают.
не, ну чтобы самому сделать, это же разбираться надо. А вдруг его свежезапиленный гениальный код на лиспе проиграет убогой несовременной сишной реализации, некрасиво же получится?))
Напомнило историю, как к нам на работу пытался устроиться еще один понторез с ЛОРа, который тут постоянно пишет «плати бабки, тогда буду мейнтейнить». Оказалось, у него в принципе нет коммерческого опыта в системном программировании)
BLAS и LAPACK делали люди, которые знали, чем и когда a*(b+c) лучше или хуже, чем ab + ac в арифметике с плавающей точкой. Поэтому даже студентов-вычислителей учат, что его переписывать не нужно.
А мне интересно полюбопытствовать (правда интересно; ни разу не «поумничать») что именно и с какой целью переписывать на лиспе? Может вопрос расширения кругозора, может там решения какие-либо интересные или там преимущества…
В фортране вот умножение матриц и массивов вообще стандарт языка (причем во многих случаях автооптимизации дают лучше, чем сторонние библиотеки).
А вдруг его свежезапиленный гениальный код на лиспе проиграет убогой несовременной сишной реализации, некрасиво же получится?))
Странная логика. Вот, если код, который немеренная туча людей 45 лет пилила, проиграет свежей библиотеке, сделанной в одиночку на коленке, тут да, некрасиво. А в обратную сторону — нормальное, ожидаемое поведение.
Я пишу на лиспе почти исключительно из-за того, что там всё динамичное (в том смысле, что заменяемое). К нему легко подключить IDE.
Например, если я найду в браузере ошибку (у меня nyxt), я могу включить swank, подключить slime, найти ошибку, исправить, посмотреть, что всё работает, а только потом добавить тесты и пересобрать.
То же самое относится к компилятору. Например, в SBCL почему-то используется сравнение, когда функции MIN/MAX применены к плавучке. Я сделал системку, позволяющую компилятору использовать MINSS/MAXSS (или MINSD/MAXSD). Для этого не надо пересобирать SBCL, надо только загрузить систему