> А что, OpenCL ядра там не соберутся?Есть шанс что соберутся и даже что будут работать, но почти наверняка неэффективно. Программировать под Xeon Phi желательно используя OpenMP и intrinsics, или хотя бы OpenMP и авто-векторизацию средствами icc. Вместо OpenMP, по вкусу, можно pthreads или даже fork() (240 раз), если делать полностью native-сборку (а не offload с хост-системы) - я проверял, работает. Векторизация в их OpenCL на данный момент не работает, если она там вообще есть. Т.е. через OpenCL получается только использование скалярной части 60-ти ядер (которая там времен первого Pentium, разогнанного на 1+ GHz), тогда как 512-битные SIMD units простаивают.
Еще одна мелкая особенность, если всё же использовать OpenCL: программы могут проверять на тип OpenCL-устройства - CL_DEVICE_TYPE_CPU или CL_DEVICE_TYPE_GPU - в то время как Xeon Phi не считает себя ни тем, ни другим, и выдает CL_DEVICE_TYPE_ACCELERATOR. Так что может потребоваться правка кода, чтобы он делал разумный для случая Xeon Phi выбор, увидев CL_DEVICE_TYPE_ACCELERATOR.
Для Litecoin mining надо подбирать оптимальный time-memory tradeoff. В майнерах соответствующий параметр назван gap, и для GPU его обычно ставят равным 2. Я не удивлюсь, если для Xeon Phi более оптимальным окажется 1, т.е. сохранение всех 128 KB (в L2 cache, которого как раз по 512/4 = 128 KB на один hardware thread), что позволит упростить и чуточку ускорить код. Ну и реализацию Salsa20 с помощью intrinsics наверняка можно написать лучше, чем это сделает компилятор - тем более, что надо реализовать от 4 до 16 экземпляров Salsa20 в одном векторе (он 512-бит, тогда как Salsa20 использует максимум 128) и выбрать какой вариант окажется эффективнее.
