Использование в своих интересах SSE и других расширений ЦП
Так много отрицательности!
я использовал XSLT в течение многих лет теперь, и действительно люблю его. Ключевая вещь, которую необходимо понять, состоит в том, что это не язык программирования, это - язык шаблонной обработки (и в этом отношении я нахожу его неопределенно выше asp.net / слюна).
XML является фактическим форматом данных веб-разработки сегодня, быть им файлы конфигурации, необработанные данные или в памяти reprsentation. XSLT и XPath дают Вам чрезвычайно мощный и очень эффективный способ преобразовать те данные в любой выходной формат, который Вы могли бы любить, немедленно давая Вам что аспект MVC разделения представления от данных.
Тогда существуют служебные способности: размытие пространств имен, распознавая разрозненные определения схемы, объединяя документы.
Это должно быть лучше иметь дело с XSLT, чем разработка Ваших собственных внутренних методов. По крайней мере, XSLT является стандартом и чем-то, что Вы могли нанять для, и если бы это - когда-нибудь действительно проблема для Вашей команды, это - очень природа, позволил бы Вам сохранить большую часть своей работы в команде только с XML.
вариант использования реального мира А: Я просто записал приложение, которое обрабатывает документы XML в оперативной памяти по всей системе и преобразовывает к JSON, HTML или XML согласно просьбе конечным пользователем. У меня был довольно случайный запрос для обеспечения как данные Excel. Бывший коллега сделал что-то подобное программно, но оно потребовало модуля нескольких файлов класса и что серверу установили MS Office! Оказывается, что Excel имеет XSD: новая функциональность с минимумом basecode влияет за 3 часа.
Лично я думаю, что это - одна из самых чистых вещей, с которыми я встретился в своей карьере, и я верю всему, ему - очевидные проблемы (отладка, обработка строк, программируя структуры) до дефектного понимания инструмента.
, Очевидно, я сильно полагаю, что это "стоит того".
5 ответов
For your second point there are several solutions as long as you can separate out the differences into different functions:
- plain old C function pointers
- dynamic linking (which generally relies on C function pointers)
- if you're using C++, having different classes that represent the support for different architectures and using virtual functions can help immensely with this.
Note that because you'd be relying on indirect function calls, the functions that abstract the different operations generally need to represent somewhat higher level functionality or you may lose whatever gains you get from the optimized instruction in the call overhead (in other words don't abstract the individual SSE operations - abstract the work you're doing).
Here's an example using function pointers:
typedef int (*scale_func_ptr)( int scalar, int* pData, int count);
int non_sse_scale( int scalar, int* pData, int count)
{
// do whatever work needs done, without SSE so it'll work on older CPUs
return 0;
}
int sse_scale( int scalar, in pData, int count)
{
// equivalent code, but uses SSE
return 0;
}
// at initialization
scale_func_ptr scale_func = non_sse_scale;
if (useSSE) {
scale_func = sse_scale;
}
// now, when you want to do the work:
scale_func( 12, theData_ptr, 512); // this will call the routine that tailored to SSE
// if the CPU supports it, otherwise calls the non-SSE
// version of the function
Good reading on the subject: Stop the instruction set war
Short overview: Sorry, it is not possible to solve your problem in simple and most compatible (Intel vs. AMD) way.
Вместо того, чтобы вручную кодировать альтернативную реализацию SSE для вашего скалярного кода, я настоятельно рекомендую вам взглянуть на OpenCL . Это независимая от производителя портативная кроссплатформенная система для вычислительно-ресурсоемких приложений (и очень модная!). Вы можете написать свой алгоритм на подмножестве C99, предназначенном для векторизованных операций, что намного проще, чем ручное кодирование SSE. И, что лучше всего, OpenCL сгенерирует наилучшую реализацию во время выполнения для выполнения либо на GPU , либо на CPU. Так что в основном вы получаете код SSE, написанный для вас.
В моей базе кода есть несколько мест, где одна и та же операция повторяется очень большое количество раз для большого набора данных. В некоторых случаях на их обработку уходит много времени.
Ваше приложение похоже на проблему, для решения которой предназначен OpenCL. Написание альтернативных функций в SSE, безусловно, улучшит скорость выполнения, но это большая работа по написанию и отладке.
Существует ли независимый от компилятора и ОС способ написания кода для использования преимуществ инструкций SSE? Мне нравятся встроенные функции VC ++, которые включают операции SSE, но я не нашел никаких решений для кросс-компилятора.
Да. Внутренние функции SSE были по существу стандартизированы Intel, поэтому одни и те же функции работают одинаково в Windows, Linux и Mac (особенно с Visual C ++ и GNU g ++).
Мне все еще нужно поддерживать некоторые процессоры, которые либо не имеют, либо ограничены SSE поддержка (например, Intel Celeron). Есть ли способ избежать создания разных версий программы, например, наличия " Может быть довольно сложно закодировать один и тот же алгоритм в разных подмножествах SSE, когда отсутствуют определенные инструкции. Я предлагаю (по крайней мере для начала) выбрать минимальный поддерживаемый уровень, такой как SSE2, и вернуться к скалярной реализации на старых машинах.
Это также идеальная ситуация для модульного / регрессионного тестирования, что очень важно. важно, чтобы разные реализации давали одинаковые результаты. Имейте набор тестов для входных данных и заведомо исправных выходных данных и прогоните одни и те же данные в обеих версиях функции обработки. Возможно, вам понадобится пройти тест на точность (например, эпсилон-разница между результатом и правильным ответом ниже
1e6). Это очень поможет при отладке, и если вы добавите время с высоким разрешением в свою среду тестирования,
Встроенные функции SSE работают с Visual C ++, GCC и компилятором Intel. В настоящее время нет проблем с их использованием.
Обратите внимание, что вы всегда должны сохранять версию своего кода, которая не использует SSE, и постоянно проверять ее на соответствие вашей реализации SSE.
Это помогает не только для отладки, это также полезно, если вы хотите поддерживать процессоры или архитектуры, которые не поддерживают требуемые вам версии SSE.
В ответ на ваш комментарий:
Так эффективно, пока я не пытаюсь на самом деле выполнить код, содержащий неподдерживаемые инструкции, я в порядке, и мне сойдет с рук " if (see2Supported) {...} else {...} "переключатель типа?
Зависит. Инструкции SSE могут существовать в двоичном файле до тех пор, пока они не выполняются. У процессора нет проблем с этим.
Однако, если вы включите поддержку SSE в компиляторе, он, скорее всего, поменяет ряд «обычных» инструкций на их эквиваленты SSE (например, скалярные операции с плавающей запятой), поэтому даже куски вашего обычного кода, отличного от SSE, взорвутся на CPU, который его не поддерживает.
Так что вам, скорее всего, придется скомпилировать один или два файла отдельно с включенным SSE и позволить им содержат все ваши процедуры SSE.