• 1
Если че, я делал simd математику в вопах, но это было на x64 и для типа регистра пользовался (complex double-float), они в x64 напрямую мапятся в xmm0-xmm9 :)

Что касается переносимости бинаря sbcl, то его и не было никогда. Даже два sbcl-я разных версий не открывают fasl-ы друг друга. И на разных машинах тоже надо все перекомпилировать.

Я летом допилил прошлогоднюю попытку Paul Khuong до некого работоспособного состояния, включая контриб, который экспортирует команды в виде функций:

https://github.com/angavrilov/sbcl/commits/sse/
https://github.com/angavrilov/cl-simd/commits/master/

Только я не знаю как довести это до включения в сам sbcl - разговоры в чате #sbcl ни к чему реальному пока не привели...

ia32 маст дай.

Ну, маст дай - не маст дай, а проблема тут, на самом деле, немного в другом. А именно - в наличии внутри одной архитектуры процессоров, реализующих разные подмножества инструкций. Вот появятся процессоры с каким-нибудь avx - и та же проблема вылезет и на x86_64.

На самом деле ИМХО единственный разумный способ реализации опциональной поддержки некоторого расширенного набора инструкций - это включение/отключение их поддержки через *features* при сборке компилятора (как, к примеру, включается/выключается поддержка нитей). Соответственно, для одной архитектуры мы сможем иметь компилятор поддерживающий расширенный набор инструкций (и не работающий на процессорах без него) и не поддерживающий, зато работающий на старых процессорах. И тут уже остаётся пользователю решать что ему важнее - бОльшая переносимость рантайма или более эффективный код.

Тут в общем как и с флагами gcc: хочешь эффективности - -O3 -march=native и вперёд, хочешь наибольшей переносимости - -march=i686 (или i386, если нужно совсем древнее тоже поддерживать).

  • 1
?

Log in