Скажите, а почему asm, а не, например, intrinsics функции в gcc?

Если у него 99% кода будет на Ассемблер, то какой смысл использовать Си? Для красивых заголовков функций? У fasm пожалуй один из самых крутых механизмов макросов, так что такой сахар можно добавить.

К тому же при работе с Intel-синтаксисом, GCC порой ужасно глючит (создаёт код некорректный с точки зрения ассемблера), а целесообразность переучивания к AT&T синтаксису под сомнением.

Посмотрел...

1) За оформление огромный плюс. Сайт надо ставить в пример многим проектам на том же SourceForge.

2) API вроде нормальный на первый взгляд, хотя я в теме не очень хорошо разбираюсь - лучше послушать тех, кому эта библиотека нужна.

3) Код меня не очень радует. FASM обладает богатейшим макроязыком, а ты практически не используешь то, что он даёт. ИМХО, следовало бы использовать различные макросы для описания функций и т. п., это бы сделало код очень читаемым и приятным.

потому что чтоб на асме писать, тебе надо будет в башке доку держать по latency всех блоков. там между прочим mov xmm1, xmm2 7 тактов занимает. дожили

Так критичные блоки всё равно придётся писать на Assembler. Иначе вся фишка его библиотеки пропадает.

А всякие вещи типа разбора параметров и поддержания структур данных погоды уже не делают.

Разумеется, если он плохой программист, то его библиотека окажется тормознее чистого Си без использования SIMD-расширений, но это уже его проблемы.

Сайт просто офигенный. Первый раз вижу такое на sf.net.

FASM обладает богатейшим макроязыком, а ты практически не используешь то, что он даёт

Я использовал тот функционал Fasm, что мне был нужен. Делать все только через макросы, тоже не вижу смысла. Как потом читать такой код. Придется постоянно прыгать и смотреть тело макроса, что он делает, какие регистры использует. Потом возвращаться в код и смотреть, а не потрутся ли данные. Идея в принципе хороша, но нужно смотреть как практически это будет реализовано и какой будет при этом код. Сможет ли кто-нибудь потом понять, что там написано и как это работает.

На макросах я хорошо оторвался в Numbers.asm. Там алгоритм извлечения вещественных чисел из строки сделан как вызовы макросов. Там не то что черт. Там я ногу сломаю, если придется срочно это перепиливать.

А вообще если есть конкретные замечания по коду или предложения как это улучшить при помощи макросов FASM, так я всегда готов послушать умного человека. Можешь написать прямо в эту ветку. Может что-то смогу улучшить.

P.S. Сайт делал от души. Опыт вебмастера не пропьешь.

Разумеется, если он плохой программист...

Вроде пока руки растут откуда нужно. А те что не оттуда - так это ноги :-)

Разумеется, если он плохой программист, то его библиотека окажется тормознее чистого Си без использования SIMD-расширений, но это уже его проблемы.

Работает быстрее. Если бы тормозила, как 8 на старом пне, то и смысла писать бы не было.

Я имел ввиду макросы вроде proc и ccall, которые активно используются в примерах fasm для Windows.

Ну я и не говорю, что ты плохой программист :-)

Если не тормозит, то хороший.

intrinsics функции

Скажите, а почему asm, а не, например, intrinsics функции в gcc?

Ну это как в том анекдоте про евреев: - Евреям сыр не продавать. - Что значит не продавать? Вы что антисемит? - Скажите, а ви это сыг пгопобавали?

Ну и мой вопрос звучит примерно так же. А вы эти intrinsics функции пробовали? У компилятора Intel C/C++ они свои, у GCC свои. Не думаю что и компилятор от ОСи зла (та что делает мелкий и мягкий софт) не будет следовать этой благородной традиции. Типа каждому компилятору свои intrinsics функции.

К тому же теряется контроль над кодом. И он потом становится такой разноцветный и пушистрый от этих интсрукций, что прямо как и хочется погладить программиста, что его написал, и желательно утюгом.

Я имел ввиду макросы вроде proc и ccall

К сожалению у FASM таких макросов нет. Зато они есть у MASM. Fasm все макросы определяет через директиву MACRO и внутри нее можно извращаться как хочешь. Специально зашел на их сайт чтобы проверить документацию. Может я где-то затупил. Но нет.

А код кстати так весь и сделан через директивы macro, поскольку я использую механизм кодогенерации на основе написанного шаблона функции на асме, просто подставляя нужные регистры и переменные.

Я специально так писал чтобы функции могли работать с разными типами данных и длинами векторов.

P.S. Кстати соглашения о вызове функции в Linux x86-64 работают через fastcall (передача параметров на регистрах а не через стек), а не через ccall или stdcall. Ну и написание программ под Windows и Linux, скажем так немного отличаются, и те примеры fasm для Windows могут быть 1) слегка устаревшими, так как они для 32 разрядной Windows, 2) следовать соврешенно другому соглашению о вызове функций, которые есть именно в Windows.

Я не ошибся и имел ввиду именно макросы proc, ccall из fasm, а не masm. Они не встроенные (и я считаю это правильно), а реализуются в виде подключаемых файлов. Их можно достать из Windows-версии.

Макрос для fastcall тоже есть. Если бы я писал подобный проект, то доработал бы стандартные макросы (для совместимости с Linux), либо написал бы свои (в последних версиях макросы шибко заумные, раньше были очень простые).

Они весьма повышают читаемость кода (приходилось работать), приближая его к языку высокого уровня, но в то же время сохраняя скорость и предсказуемость.

Если что могу написать хоть сейчас, как примерно они должны выглядеть.

Если кратко — какие алгоритмы там реализованы? Видели, например, liboil?

Ах да, и зачем там С++?

Если у него 99% кода будет на Ассемблер, то какой смысл использовать Си?

Принимая во внимание небольшой размер многих функций, для того, чтобы компилятор мог провести инлайнинг (а icc и вовсе может IPO для библиотеки выполнить).

Напрасно вы решили переизобретать функции libc. Вряд ли кто-то станет этим пользоваться. Если вы знаете как сделать быстрее, чем в glibc — шлите патчи в рассылку разработчиков glibc.

Интерфесы на C++... Во-первых, это резко ограничивает возможности применения. Во-вторых... зачем???

collection of fast libraries

Есть тесты, сравнивающие производительность с Intel MKL и glibc?

LibOil b C++

Если кратко — какие алгоритмы там реализованы? Видели, например, liboil?

Видел. Правда проект немножечька не живой. А помоему очень даже не живой. Смотрел их код. Там много функций с пометкой: рализовать или не правильно работает. Может мне просто попалось их старое зеркало, но основной итог таков. Тот проект мертв.

Ах да, и зачем там С++?

Там С++ не зачем. Бибилиотеки писаны для С++ а теперь и для С (добавил и его поддержку) чтобы ускорить на нем рутинные действия за счет использования оптимизированного кода. Это нужно когда есть большой объем данных, который нужно быстро проанализировать. Задача проекта, изначальная задача, была анализ временных рядов. И там высокоуровневый код писали на С++. Математическая обработка данных там работала ужасно «быстро». Именно ужасно. Поэтому этот код и форкнули на fasm и теперь он линкуется из С++.

Напрасно вы решили переизобретать функции libc

Там функции из libc реализованы только в 3 модулях, и то те которые в самой libc работают очень медленно. Переизобретать GNU libc не вижу смысла. Поэтому сделал только те куски которые нужны были проекту, и в самой библиотеке были не очень хорошо написаны.

Интерфесы на C++... Во-первых, это резко ограничивает возможности применения.

Там теперь также реализованы интерфейсы на С, чтобы расширить применение кода в проектах на С.

Во-вторых... зачем???

Потому что этот код - часть другого проекта, который написан на С++. Поэтому и интерфейс был в первую очередь реализован для него.

Есть тесты, сравнивающие производительность с Intel MKL и glibc?

Есть. Но пока только с glibc и только для тех функций, где есть аналоги в libc. Как будет реализован полный набор всех функции, который мне будет нужен, так сделаю сравнение и с MKL

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
stepping        : 7
cpu MHz         : 3160.503
cache size      : 6144 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc rep_good pni ssse3 lahf_lm
bogomips        : 6321.00
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

################################################################################
#       Numbers conversion library speed test                                  #
################################################################################
This test converts 1000000 numbers in 100 rounds.

Integer numbers conversion:
===========================

Octal numbers conversion:
    'sscanf' time: 19.755847 sec
    'strtoul' time: 5.476777 sec
    'LinAsm' time: 2.952698 sec

Hexadecimal numbers conversion:
    'sscanf' time: 19.364499 sec
    'strtoul' time: 6.264688 sec
    'LinAsm' time: 4.190943 sec

Decimal numbers conversion:
    'sscanf' time: 18.347976 sec
    'strtoul' time: 5.220468 sec
    'LinAsm' time: 2.785372 sec

Floating-point numbers conversion:
==================================

Hexadecimal numbers conversion:
    'sscanf' time: 26.137860 sec
    'strtod' time: 10.961610 sec
    'LinAsm' time: 5.795652 sec

Decimal numbers conversion:
    'sscanf' time: 27.214856 sec
    'strtod' time: 15.222347 sec
    'LinAsm' time: 2.954274 sec

################################################################################
#       Time conversion library speed test                                     #
################################################################################
This test converts 1000000 time stamps in 100 rounds.

Unix time to Gregorian date conversion:
    'gmtime' time: 4.228890 sec
    'LinAsm' time: 2.284649 sec

Gregorian date to unix time conversion:
    'mktime' time: 122.046674 sec		# Это не шибка. Такой вот код в libc
    'LinAsm' time: 1.005384 sec

################################################################################
#       Array library speed test                                               #
################################################################################
This test operates on 10000000 elements wide flt64_t arrays in 100 rounds.

Addition:
    Classic scalar code time: 1.407980 sec
    LinAsm vector code time: 1.379985 sec

Subtraction:
    Classic scalar code time: 1.426498 sec
    LinAsm vector code time: 1.379655 sec

Multiplication:
    Classic scalar code time: 1.397805 sec
    LinAsm vector code time: 1.386163 sec

Division:
    Classic scalar code time: 6.425936 sec
    LinAsm vector code time: 3.445004 sec

Absolute value:
    Classic scalar code time: 1.008767 sec
    LinAsm vector code time: 0.921362 sec

Square root value:
    Classic scalar code time: 11.988184 sec
    LinAsm vector code time: 2.745969 sec

Min value:
    Classic scalar code time: 1.329877 sec
    LinAsm vector code time: 0.665184 sec

Max value:
    Classic scalar code time: 1.320772 sec
    LinAsm vector code time: 0.665314 sec

Convolution value:
    Classic scalar code time: 1.269394 sec
    LinAsm vector code time: 1.083574 sec

Sorting:
    Classic Quick Sort code time: 1.848767 sec
    LinAsm Quick Sort code time: 0.770507 sec
    LinAsm Radix Sort code time: 0.332851 sec

Сравнение производительности хорошо бы вывесить на сайт. Потому что это первый вопрос, который возникает по поводу вашей библиотеки.

Тест производительности

Хороший совет. Сегдня сделал страничку сравнивающую производительность библиотек для тех функций, которые имеют аналоги в GNU libc. Многие их не имеют, так что тесты сравнивают лишь небольшой набор одинаковых по функционалу алгоритмов. Графики прилагаются.

Ссылка на тесты вот: http://linasm.sourceforge.net/about/performance.php

У компилятора Intel C/C++ они свои, у GCC свои,... компилятор от ОСи зла

вроде в использовании ничем не отличается, другое дело, что в gcc есть расширение для векторных типов данных, что гораздо удобнее и интринсиков, и библиотек.

теряется контроль над кодом

с этим согласен.

Смотрел некоторое время назад доки, но подзабыл:
какие именно SIMD-расширения используются, в частности, из актуальных:
AVX
MVEX/VEX (Intel MIC)
?

вот здесь http://linasm.sourceforge.net/docs/api/numbers.php в первой секции Binary numbers conversion дважды написано Signed integer types

Спасибо

Спасибо за то, что нашли ошибку. Уже все исправил. Теперь порядок.

SIMD расширения

Смотрел некоторое время назад доки, но подзабыл:
какие именно SIMD-расширения используются, в частности, из актуальных:
AVX
MVEX/VEX (Intel MIC)

AVX пока еще экзотика. Еще не у всех есть процессоры с поддержкой этого расширения. Поэтому используется sse, sse2, sse3. Потому что есть практически везде сейчас.

intrinsics функции

вроде в использовании ничем не отличается, другое дело, что в gcc есть >расширение для векторных типов данных, что гораздо удобнее и интринсиков, и >библиотек.

Тут все неудобство в том, что каждый производитель компиляторов считает своим долгом придумать свои названия для этих функций. Поскольку не один стандарт не регламментирует их имена, каждый волен сам их выбирать.

И когда пытаешь портировать программу под другой компилятор, к примеру с GCC на Intel C compiler, то последний начинает страшно ругаться на непонятные ему intrinsic функции.

А в способе работы этих функций, ни каких различий нет. Ведь это простые ассемблерные директивы, на вызов обычных встроенных процессорных инструкций. И нет совсем никакой разницы, зовете ли ли вы их через intrinsic имена или напрямую из асм кода.

sse, sse2, sse3. Потому что есть практически везде сейчас

кем Вы себе представляете потенциального пользователя Вашей библиотеки?
sse/sse2 появились более 10 лет назад, и за эти 10 лет те программисты, кому было это нужно --- так или иначе приспособились их использовать. Зачем им все переписывать?

AVX пока еще экзотика

Вот именно потому еще остается некий шанс, что тот, кто только собирается векторизовать свою программу --- обратит внимание и на LinAsm/AVX. Причём на Вашем месте я бы вообще ориентировался даже не на AVX, а на VEX --- рано или поздно Intel встроит его и в обычные процессоры.

А так, если сравнивать скалярный AVX, поддерживаемый всеми актуальными компиляторами, с векторным SSE2, то первый еще и быстрее может оказаться, особенно на Бульдозер-е.

И нет совсем никакой разницы, зовете ли ли вы их через intrinsic имена или напрямую из асм кода

разница есть. Интринсики в C-шном коде компилятор оптимизирует как и все остальные инструкции. а ассемблер (даже инлайн) --- нет.

Замечание правильное. Но вот, как я написал ранее, для алгоритма нет никакой разницы как вы их вызовете. Их функционал от этого не поменяется никак.

То что компилятор постарается оптимизировать код intrinsic функции это здорово. Но разница эта только для компилятора. В итоге все равно будет вызвана та же самая процессорная инструкция. Если вы хотите получить значительное ускорение от кода, то тут уже нужно применить более мощную оптимизацию, и делать ее придется вам.

Можно конечно провести тесты: использовать intrinsic и asm. И даже доказать самому себе и всем вокруг что код intrinsic быстее процентов на 5-10 чем asm. Но компилятор вам не сделает прироста в скорости в 2 раза просто от того что он заоптимизировал вызовы intrinsic функций.

Именно вы как программист пишите программу и знаете тонкости работы своего алгоритма. Компилятор вам только оптимизирует тот код, что он понимает. Они хоть и стали интелектуальнее, но не на столько чтобы думать самостоятельно.

Видел. Правда проект немножечька не живой. А помоему очень даже не живой. Смотрел их код. Там много функций с пометкой: рализовать или не правильно работает. Может мне просто попалось их старое зеркало, но основной итог таков. Тот проект мертв.

liborc

sse/sse2 появились более 10 лет назад, и за эти 10 лет те программисты, кому было >это нужно --- так или иначе приспособились их использовать. Зачем им все >переписывать?

А им и не нужно ничего переписывать. Достаточно сделать вызов простой функции из библиотеки. То что они существуют более 10 лет - так это здорово. Значит их поддержка есть на всех современных процессорах, кто делал upgrade в течении последних 10 лет.

AVX пока еще экзотика
Вот именно потому еще остается некий шанс, что тот, кто только собирается векторизовать свою программу --- обратит внимание и на LinAsm/AVX

Вы бежите впереди паровоза. Мы можем кричать, давайте вообше писать под квантовые процессоры. Они будут популярны через 5-10 лет (как им кажется). Но мы живем сейчас. И реальность такова, что AVX есть не у всех. И для решения текущих задач сего дня, нам нужно ориентироваться на то что есть уже сегодня.

Когда мне нужно сейчас решить какую-то задачу, я не буду ждать когда через год выпустят процессор, который сможет ее решить. Мне решение нужно уже сейчас Когда AVX будет везде - тогда выпущу релиз с поддержкой AVX или чего-то еще что прийдет ему на смену. Нужно быть реалистом, а не загадывать какой сорт яблок через 50 лет будут выращивать фермеры на Марсе.

А так, если сравнивать скалярный AVX, поддерживаемый всеми актуальными >компиляторами, с векторным SSE2, то первый еще и быстрее может оказаться, >особенно на Бульдозер-е.

Очень может быть. Но сначала всем массово нужно сделать upgrade своим компьютерам, чтобы иметь возможность в этом самим убедится.

Вообше говоря, те кто пишут программы - ориентируются не на то железо, что может быть появится завтра, а на то, что уже есть сегодня. Потому что программы нужно тестировать, отлаживать, проверять их быстродействие, и они должны уже сейчас решать текущие задачи, а не в далеком будущем. Там может вообще измениться и архитектура процессоров или добавятся вычисления на встроенных GPU последних Intel-ов, так что даже AVX станет устаревшим рудиментом. Мне этого не известно. Поэтому если у вас есть конкретная задача, вы ее решаете доступными вам методами, а не теоретизируете на этот счет.

Если есть вопросы или предложения по существу - с удовольствием на них отвечу. А так у нас просто полемика ни о чем.

Этот проект уже получше. Правда меня немного смущает дата последнего релиза orc-0.4.16.tar.gz 03-Oct-2011 00:51

И само описание проекта

Orc is a just-in-time compiler implemented as a library and set of associated tools for compiling and executing simple programs that operate on arrays of data. Orc is unlike other general-purpose JIT engines: the Orc bytecode and language is designed so that it can be readily converted into SIMD instructions. This translates to interesting language features and limitations: Orc has built-in capability for SIMD-friendly operations such as shuffling, saturated addition and subtraction, but only works on arrays of data. This makes Orc good for applications such as image processing, audio processing, array math, and signal analysis.

The Orc language is an assembly-like language, where the programmer specifies the operations to be done on each element of one or several arrays. The Orc tools then convert this into an intermediate form (as C source code) that includes the bytecode, functions for automatically calling the compiled bytecode from C, and backup functions (in C) that are used when Orc is not available or unable to compile the bytecode into efficient SIMD code. Orc generates code optimized for the specific processor that is running, using instruction sets that are available.

Since Orc creates backup functions, you can optionally use many Orc-using libraries and applications without actually having the Orc library — this is useful for transitioning an application into using Orc. However, when Orc is disabled, the application is unable to use the SIMD code generated by Orc.

Т.е. это язык и генератор байткода. Мне стоит для того чтобы сложить два массива еще и язык новый освоить? И поставить генератор, который мою программу потом загонит в байт код, а потом умный интерпретатор его будет перегонять в инструкции процессора.

Новые знания - это конечно хорошо. Но зачем для простых задач использовать столь сложный инструмент. Помоему вызов одной простой функции будет быстрее и проще. Исправьте меня, если я говорю ерунду.

Orc’s most unique feature is that a program can generate Orc bytecode at runtime >and it will be compiled into efficient SIMD code.

А помоему эффективней это будет сделать всего один раз на этапе компиляции. И на счет эффективности того кода что он мне нагенерирует я вообще не уверен. Там будет ровно такая эффективность, насколько умен сам этот orc и программист что писал его оптимизатор.

Программист , который знает что он пишет, сгенерирует код гораздо эффективнее, чем компилятор, не знающий что хотел сказать программист этими своими строчками кода.

Не верите. Напишите программу на java и на С. И сравните скорость работы той и той. И конечно же используйте умную оптимизацию обеих платформ. Пусть умные компилятор и интерпретатор сделают свою славную работу, а мы на них посмотрим.

liborc

Вообще это выглялдит как мягкая попытка сказать мне: Слушай, на кой черт ты вообше решил что-то там писать. Не стоит этого делать. Смотри вон кучи всяких класных проектов уже сделаны и без тебя. Да, там есть свои проблемы и не доработки. Некоторые уже померли, но вот есть новые, и посложнее и покруче старых. И вообше настоящие программисты код не пишут, они тырят его у других.

Я отвечу. Все это конечно хорошо, но когда у вас появляется реальная и нетривиальная задача, очень часто приходится садится и перерабатывать или чужой кем то давно написанный код, или писать свой собственный, потому то аналога ему нет или использование чужого кода вызывает свои трудности.

И LinAsm, это как раз проект из области, где разработки других пока отсутствуют. Цель проекта - анализ временных рядов, там нужны и работа с масивами и цифровые фильтры и методы робастной статистики и преобразования большого количества входных данных из разных форматов. То что часть функций есть где-то еще, не снимает проблемы интеграции всех сторонних разработок в один пакет с общим интерфейсом. И если те разработки еще тянут за собой кучи зависимостей и языков программирования, то порой становится проще вырезать пару функций или разработать свои. Быстрее по времени и сопровождать их потом легче.

Слушай, я просто скинул ссылку на проект, который является развитием liboil.

Но твой баттхёрт на эту тему доставляет, да 8). Я даже понял, что liborc, по сравнению с твоим проектом, обладает одним фатальным недостатком...

Спасибо, добрый человек. Я не понимаю, что ты написал, зачем, я просто говорю тебе: «Спасибо!!!».

liborc

Господа, не поймите меня превратно. Просто все считают своим долгом поработать за старину Google. И скинуть мне пару ссылок, на другие проекты, даже не разобравшись в том, а насколько они близки к данной тематике.

Проект liboil просто реализовывал функции для работы с массивами. И это все что он делал. Проект сейчас мертв, причем умер даже не успев нормально развится. Внутри он так и остался сырой (куча Fixme, Wrong value). Там нет ни статистической обработки этих массивов, ни DSP ни даже фильтрации данных. Как он может помочь в анализе временных рядов? Ответ: никак. В LinAsm билиотека работы с массивами, лишь небольшая часть этого проекта (причем не основная), к тому же оптимизирована для многопоточной работы и использования векторных расширений процессора.

liborc - это вообще язык и bytecode компилятор, который якобы продолжает liboil. Чтобы все это работало, там нужен этот самый bytecode компилятор, который будет, как утверждает разработчик, создавать эффективный SIMD код (что очень сомнительно). К тому же что бы писать на этом liborc, нужно освоить этот ассемблероподобный язык программирования.

Вопрос: Зачем вносить дополнительные усложнения в достаточно простую задачу? Ответ: Не за чем.

Какое преимущество он даст, вместо того чтобы самостоятельно написать тот же самый векторный код, хотябы на тех же intrinsics? Все равно прийдется учить liborc ассемблер или x86-ассемблер. Преимуществ никаких.

Реализовано ли там что-то для работы в временными рядами? А простейшие фильтры? Статистика? Нет ни того не другого. Все что он делает - работа с массивами, через свой собственный байт-компилятор, и язкык, который нужно сначала выучить.

Т.е. ссылка что ты прислал - это как последний аргумент в споре. Мол Калсон улетел, но обещал вернуться, причем с друзьями и пол литрой.

Мне бы хотелось услышать замечания по существу: по проекту, качеству кода, его понятности, уровню документации, а не получить коллекцию ссылок от Google. Если даете ссылку, будьте добры сначала посмотреть, чем тот хрен этой редьки слаще.

Обширные знания в проектах OpenSource и умение пользоваться Google - это конечно круто. Но было бы лучше, если бы были приведены четкие агрументы, как те разработки могут помочь или улучшить проект, или что именно они делают лучше, чем то что сделано у меня.

Я был бы вам признателен за конкретные замечания, а не рассуждения общего плана или пустое теоретезирование.

Всегда пожалуйста.

Спасибо, добрый человек. Я не понимаю, что ты написал, зачем, я просто говорю тебе: «Спасибо!!!».

Ну что тут можно ответить на такие теплые, милые и дружеские слова. Только: «Автору - респект и уважуха.» А если будут замечания по теме поста, то вообще будет нескончаемый пожизненный респект.

Давайте не будем преврашать эту ветку в флейм и прочее тро-ло-ло. Говорите по существу.

Автор, глубоко вдохни, успокойся и почитай внимательно: http://code.entropywave.com/documentation/orc/orc-concepts.html. И пойми, что у liborc совершенно другой подход. У тебя, как и в liboil, - набор конкретных функций, заточенных под определённое применение. Внутри liborc - кроссплатформенный SIMD-компилятор, возможности которого шире из-за отсутствия заранее заготовленного фиксированного набора функций. Можешь ещё почитать по каким причинам отказались от liboil и перешли на liborc.

Вы бежите впереди паровоза

ну как сказать... специально скачал linasm, написал простенький тест на Array::SumMul

const int sz=1024, num=1000000;
int main(int, char**) {
  double Arr1[sz], Arr2[sz];
  double tStart=omp_get_wtime(), tDur=0.0;
  Array::Init(Arr1,sz, 1.0/sz);
  Array::Init(Arr2,sz, 1.0);
  double res=Array::SumMul(Arr1, Arr2, sz)-1.0;
  tStart = omp_get_wtime();
  for(int i=0; i<num; i++) {
    for(int j=0; j<sz; j++) {
      res += Arr1[j]*Arr2[j];
    }
  }
  tDur = omp_get_wtime()-tStart;
  printf("Simple for\t %g, %.3g GFlops, %.3g sec\n", res-=num, 2e-9*sz*num/tDur, tDur);
  tStart = omp_get_wtime();
  for(int i=0; i<num; i++) res += Array::SumMul(Arr1, Arr2, sz);
  tDur = omp_get_wtime()-tStart;
  printf("LinAsm    \t %g, %.3g GFlops, %.3g sec\n", res-=num, 2e-9*sz*num/tDur, tDur);
 ...
}

$ g++ -Iinclude -L. -fopenmp -march=bdver1 -Ofast -o Test Test.cpp -llinasm;./Test
Simple for       0, 6.18 GFlops, 0.332 sec
LinAsm           0, 2.4 GFlops, 0.852 sec
Opt. for         0, 9.07 GFlops, 0.226 sec

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 21
model           : 1
model name      : AMD FX(tm)-6100 Six-Core Processor             

AVX

Интересный результат. Заставляет задуматься. Конструктивная критика - это всегда хорошо.

Хотелось бы получить исходники самих тестов, и комментарии по поводу них. Как они проводились, какое расширение использовалось. Короче иметь возможность воспроизвести тест и повторить результат. Мой почтовый адрес указан на сайте LinAsm в разделе Contacts. Скидывайте на любой из двух адресов.

AVX даже чисто теоретически может ускорить вычисления в 2 раза. Правда пока есть не у всех. Тут либо нужно делать полный апгрейд, либо искать у кого уже стоит процессор с их поддержкой. Можно конечно сделать fork библиотеки и под них. Но пока это просто не мейнстрим. Эти расширения появились относительно недавно, и многими платформами пока не поддерживаются. Но в любом случае, выигрыш в скорости, конечно будет. Нужно думать.

Заранее спасибо за тесты.

Вдохнул, почитал.

Достаточно интересный прект. Полистал их документации и описаловку по библиотеке и механизме кодогенерации. Ребята конечно молодцы, решили сделать векторный код портируемым, через динамическую кодогонерацию, там где есть соответствующие векторные расширения.

Проект забавный и интересный. Мне правда с ними немного не по пути. Не хочется тянуть в свой код еще bytecode компилятор, потеряется всякий контроль над програмным кодом + нужно иметь эту runtime библиотеку или генерировать через liborc тот же самый векторный код во время сборки проекта. Короче это дополнительная сложность, которая хороша для кросплатформенных решений, где нужно чтобы работало с минимальными исправления на широком диапазоне процессоров. Где есть какое-либо из векторных расширений.

Для моего проекта такая задача не стоит. Там целевая платформа одна. Плюс грамотно написаный векторный код, как мне кажется, будет проще сгенерировать один раз, чем создавать его каждый раз во время компиляции. И тут лучший вариант - написать его руками с полным пониманием дела, и того что он должен делать и как это будет работать с железом.

Короче вывод. Проект хороший, но мне он не сильно может помочь. Ибо у нас с ним разные задачи.