Maple 9 и DLL на Visual С++ 2005 Express Edition

[gevaraweb]

И еще, все-таки, Maple у вас староват. Новые версии, по идее, должны лучше работать с многоядерныи процессором. Может и скорость бы возросла.
Конечно, нужна лицензия ) Может сочетание "Maple 2015 и DLL на Visual С++ 2005 Express Edition" даст вам нужную скорость.

[GAA]

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

1. Если обращения к каждому из массивов (списков) происходит не много раз, то, возможно, для увеличения скорости лучше читать данные Maple из dll (т.е. иметь в dll функцию получения данных из Maple (передавать массивы), а не писать в дисковый файл и читать из файла). [Конечно, для продолжения работы с данными можно сохранять данные dll на диске, а при следующем запуске читать. Но если в дальнейшем данные не будут нужны, то немного выигрываем по времени.]

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

2. Если же работа с отсортированными массивами не подходит, а лучше перебирать элементы массива пока не будет найден искомый элемент или не пройден весь массив, то вместо scasw, я бы попробовал воспользоваться AVX или SSE (если процессор достаточно стар).

Я попробовал быстро набросать две функции: 1) c scasw, 2) с инструкциями SSE.
Если предположить, что массивы заведомо не будут содержать некоторое число (например, 0 или максимальное двухбайтовое), то функция c SSE может быть очень простой. При создании массива его размер делаем кранным восьми word. Если исходные данные не занимают весь массив, в свободные элементы пишем число, которое не может в нём встретиться и которое не будем в нём искать.

При поиске читаем по 8 слов и проверяем: нет ли среди них искомого числа. Если есть, то выходим из цикла и возвращаем истину (в приводимом ниже коде 1). Если же не находим, то повторяем чтение пока не пробежим весь массив.

Используется синтаксис ASM

// Функция на основе scasw
// rcx - длину массива в словах
// rdx - содержит искомое число
// r8 – адрес массива с данными
// rax – результат
    push    rdi
    mov     rdi,   r8
    mov     rax,   rdx
repne scasw
    je      @@Ok
    xor     rax,   rax
    jmp     @@Exit
@@Ok:
    mov     rax, 1
    jmp     @@Exit
@@Exit:
    pop rdi

Используется синтаксис ASM

// Функция на основе SSE
// rcx – содержит длину массива в словах
// rdx – содержит искомое число
// r8 – адрес массива с данными
// rax – результат
 mov      rax,  rdx
 shl      rax,  16
 or       rax,  rdx
 movq     xmm1, rax
 pcmpeqb  xmm2, xmm2   // generate mask 1
 pshufd   xmm1, xmm1, 00000000b  //
@@rep:
 movaps   xmm0, xmm1
 pcmpeqw  xmm0, [r8+rcx*2-16]
 ptest    xmm0, xmm2
 jnz      @@Ok
 sub      rcx,  8
 jnz      @@rep
 xor      rax,  rax  // Число не найдено в массиве
 jmp      @@Exit
@@Ok:                // Число найдено в массиве
 mov      rax,   1
@@Exit:

Я не оптимизировал функцию, но даже при таком черновом написании вторая функция выполняется быстрее первой более чем в 5 раз. Я сильно не проверял, поэтому стоит перепроверить, если использовать.
[Upd. (8.12.2015)] Времена выполнения сравнивались на Sandy Bridge, в системе была установлена достаточно медленная память DDR3 1333.[/Upd]

-- Пн 07.12.2015 18:36:47 --

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

[aa_dav]

GAA в сообщении #1080355 писал(а):

1) c scasw

Замечу, что Intel до архитектуры Ivy Bridge не рекомендовал использовать строковые инструкции вообще, если вы хотели добиться скорости. На более старых архитектурах Intel цикл из mov/cmp был быстрее, не говоря уже о SSE. И только в Ivy Bridge они соптимизировали всё нормально. AMD сделал это годами ранее.