Меня интересуют высокоэффективные билиотеки для работы на x86 машинах. При этом очень важно, чтобы используемый код МАКСИМАЛЬНО использовал возможности процессоров Intel, AMD и Cyrix. При этом был бы встроенный механизм автоматически определять тип процессора и, если будет возможность, ядра. Хотелось бы, чтобы было в виде dll менеджера + dll для каждого ядра. В библиотеке должны быть как минимум реализованы все существующие контейнеры (различные модификации tree, map, list, array), а также операции на памятью (memset, memmove и т.д.).

Если кто нибудь знает о существовании таких библиотек (платных или бесплатных) сообщите, пожалуйста.

PS: варианты использования STL и иже с ним не подходят, т.к. упираются в возможности компилятора. Intel C++ генерирует эффективный код, но программа не будет работать на Cyrix или AMD (а при оптимизациях для Prescott и на предыдущих ядрах P4). VC++ несмотря на серьезный шаг вперед все еще не в состоянии использовать возможности процессоров на все 100%. GCC не подходит из-за необходимости разрабатывать под Windows.

Необходимы библиотеки для эффективного управления памятью, а также все базовые контейнеры. Если будут реализации базовых алгебраических преобразований (max, min, trunc, round, frac и т.п.) будет еще лучше.
Объясню на примере:
при чтении из памяти для PIII, Athlon, AthlonXP необходимо использовать software prefetch тип 1, для Athlon64/Operton software prefetch тип 2, для P4 - выстроить запросы на доступ к пямяти с шагом 4K для hardware prefetch. Для записи данных в память нужно использовать Non temporal store. При этом нужно учитывать то, что для PIII и P4 нужно использовать SSE, для Athlon, AthlonXP, Athlon64/Operton - MMX.
В контейнерах можно сделать тоже оптимизации: для tree и list - группировать элементы по банкам памяти, для map использовать заточенные под используемый процессор функции вычисления индекса (например для string map).
Насчет max и min - у меня самого есть реализации без ветвления (любое ветвление приводит процессор в легкий шок), но только для __int32 (и соответственно float), а вот для __int64 (double) эффективной реализации нет, вернее есть моя, но она не очень-то :(. В этом случае прямо напрашивается использование MMX.
Trunc можно на Prescott реализовать с помощью SSE3.
Теперь о самой задаче:
У нас есть данные (несколько файлов, содержащие по несколько миллионов строк. Строк более 10000000 в каждом файле), расположенные на диске, необходимо реализовать расчеты, где присутствуют поиск и сортировка.
Почему не используются существующие БД - это ведь их задача? Результатом вычисления есть файл в десятки миллионов записей. fetch для ТАКОГО кол-ва записей просто убъет сеть, да и будет несколько дней: я потренировался на "кошках" 3200 записей из Oracle извлекаются за 14 с. (переработанный мной компонент для Delphi, использующий OCI - оригинальный извлекал за 21 c). Если учесть эту скорость и считать, что она не будет изменяться (а это в корне не верно), то даже при этих весьма оптимистичных (скажу так - нереальных) допущениях данные в файл попадут через 5 дней. А еще необходимо учесть время выполнения запроса...
И напоследок, кол-во памяти не играет роли: на машине установлено 4GB и Windows запускается с /pae /3gb. Компиляцию для 3gb я при необходимости выставлю ;) Нужно максимально минимизировать время формирования результирующего файла.

CEMb2 Ярослав Татаренко

А где можно почитать про методы работы под разными платформами? Я знал, что они отличаются, но не думал, что всё так запущено :)

www.amd.com настоятельно рекомендую почитать AMD Athlon™ Processor x86 Code Optimization Guide
www.intel.com IA-32 Intel Architecture Optimization

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

Изменение исходных данных происходит раз в месяц. Но объемы растут как на дрожжах: если еще полгода назад объемы таблиц были в несколько тысяч записей, то сейчас уже десятки миллионов, а дальше - больше. Я пока не вижу смысла использовать БД: необходимо сначала ввнести исходные данные в таблицы, а потом выгрузить результаты в файл. Если уважаемый Lepsik поможет разобраться с BULK операциями, то, возможно, будет иметь смысл рассматривать БД.

Tracer
А заморачиваться с оптимизацией под конкретные процы я бы не советовал, уж больно часто они меняются

Не согласен. P4 вышел в свет в 2000 с тех пор его архитектура не изменилась, а в свете последних планов Intel относительно развития в сторону многоядерности, изменение архитектуры будет незначительным. Примерно то же относится и к AMD. Т.е. использование оптимизаций под конкретные процессоры дает выигрыш и будет актуально еще лет 5-7.

Алексей КубенкоПомоему вы изобретаете велосипед.
Базы данных были как раз придуманы для того что бы разработчик не задумывался о том, как организовано, хранение данных. Завтра у вас немного изменяется файл вам придется переписывать вашу программу оптимизировать рассчет вашего файла с результатами (хорошо если он всего 1 а если их 10 или 20) из-за того что изменилась структура. Вместо того что бы немного изменить процедуру импорта данных в базу и посмотреть планы выполнения критичных запросов и в случае необходимости оптимизировать их.

Возможно я все таки не прав.
Но и вашего объяснения не совсем понятно задание.


К сожалению, сообщить более подробно не имею права.

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


Каждый месяц появляются НОВЫЕ данные, которые никак не соотносятся и не пересекаются с иходными данными предыдущей обработки. Рост объема данных определяется, допустим, увеличением точек замера и частотой замера (это только для примера, на самом деле это не так. объяснить не могу - не имею права)

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

Это покажется многим глупостью, но это политика конторы: доступ к серверу закрыт. У вас 1521 порт - вот и пользуйтесь им.

Алексей Кубенко
Что-то медленно ваш Oracle извлекает данные или это так у вас влияет сеть или надо другими способами извлекать данные (использовать другие библиотеки/компоненты/утилиты).
Например у меня на машине(P4 1.8Ghz /512MB/ 3xHDD40Gb - это и сервером назвать страшно, на рабочую станцию не тянет) на которой стоит сервер MS SQL Server выгрузка 636603 записей при помощи
bcp.exe "db..t_table" out test.txt -c -CRAW -SSomeServer -Usa -P
выполняется за 9805ms, при этом формируется файл на 49 метров, размер 1 записи составляет 31 байт.

тестовая машина клиент: Celeron 1,7GHz/400MHz FSB/256MB DDR266 CL2,5/IDE HDD IBM 40GB
тестовая машина сервер: P4 2,0GHz/533MHz FSB/512MB DDR333 CL2,5/IDE HDD IBM 60GB
сеть 100Mb/s. Реальная скорость: 30-35Mb/s
Программа написана на Delphi, компонент NCOCI 1.0. Компонент был весьма быстрым (по fetch самым быстрым среди всех Delphi компонент).

Алексей Кубенко
Вот здесь как раз вы не то время считаете нужно считать время не то которое потратится на fetch данных, а время за которое выполнится запрос (конечно если вам не требуется сформировать отчет за 1 секунду), при условии если делать формирование вашего файла на сервере например каким нибудь DCOM объектом.
Оценить время выполнения запроса я могу лишь относительно. Абсолютно - нет. Понятно, что выполнение запроса будет меньше, чем извлечение результатов. По этому я оцениваю время выполнения самой долгой операции - операции извлечения результатов.

Я все же начал писать библиотеку.
Т.к. у меня дома AthlonXP, а на работе Intel, то приходится писать под оба процессора. Результаты уже наводят на мысль, что я на правильном пути. По предварительным оценкам данная задача будет выполняться примерно 15-20 мин без учета загрузки и выгрузки данных. Загрузка предположительно будет около 0,5 часа, а выгрузка примерно 15 мин. Возможно я не совсем точно расчитал, но в порядке не ошибся.

Вопрос сможет ли MSSQL или Oracle достичь скорости INSERT порядка 600зап/сек, а FETCH порядка 10000зап/сек на тестовом сервере? Если да, по подскажите каким образом нужно настроить сервер и какой библиотекой нужно пользоваться для связи с ним.

Mik ProkoshinВы бы не парились с этими самостоятельными библиотеками ! Компилятор Вам фору даст с вероятностью 95%.

Боюсь что уже не так. Написанные мною функции memset, memcpy и memmove превосходят аналогичные библиотеки по скорости на VC++ примерно в 4-6 раз.
Класс array превосходит примерно на 80%, но он еще не до конца профилирован. Так что фора, боюсь, мне не нужна. ;)

Mik Prokoshin
И ведь потом придется в одиночку свой Оракл реализовывать. Прикиньте время. И не факт, что Вам удастся оптимально реализовать все необходимые алгоритмы.

Дело в том, что на предыдущей работе я уже делал свою БД. Это была не SQL платформа, да и к тому же она была исключительно для узких целей (мониторинг деятельности бирж). Написана была на Delphi. Скорость вставки/обновления у нее было в рабочем режиме примерно 24000 зап/сек при длине записи в 32 байта. Предельная скорость - примерно 56000 зап/сек. Сервер способен был одновременно работать с 600 клиентами в режиме запроса-ответа. При этом данные извлекались со скоростью 10000-12000 зап/сек. Аппаратная часть: Dual Intel PIII 800MHz/2GB SDRAM/IDE HDD IBM 250GB.
Уже тогда я обратил внимание на неоптимальность и неэфеективность генерируемого Delphi кода. Решил написать критические участки на VC++, но не получил никакого выиграша. Попытка использовать в Delphi SSE привела к исключению incorrect instruction set. Этот же самый код в VC++ работал великолепно.

Mik Prokoshin
Найдите лучше хорошего ораклоида. Он Вам сделает проект (архитектуру), укажет необходимое железо (а для задач такого плана явно надо использовать выделенное железо с определенными характеристиками). Оракл ПРЕДНАЗНАЧЕН для проектов аналогичного уровня.
Учтите также, что Вашего сервера (его винтов и выч. мощности, хотя бы винты-то SCSI ?) скорее всего (да с вероятностью 85%) не хватит на данную задачу. Просто можно спрогнозировать : десятки миллионов за полгода (возмем 50млн.) - это за пять лет - 250 млн. Если запись - по 0,5Кб, в результате надо 130 Гб на Вашу базу.

Вы наверняка бы были правы, если бы программист на территории СНГ получал бы от 5000$ в мес. Тогда бы покупка дополнительных 20 процессоров было бы более экономически обоснована, чем лишний месяц работы программиста.

Mik Prokoshin
А с нуля СУБД писать, оптимизированную под процессоры... Ну ей-богу, у нас когда-то один деятель тоже об этом мечтал. Исключительно на ассемблере реализовывать собирались, крупными силами. На довольно высоком посту был. Слава богу, вовремя остановили и вообще выпнули. Студенчество это играет. Хотя - дело Ваше.

Почему с нуля? В технической библиотеке достаточно книг по архитектурам БД. Вот попытка действительно с нуля написать такое - это уж точно студенчество, а взвешенный подход и отсутствие амбиций, как то напишем за 2 года БД, которая, извините, уделает Oracle, дает довольно неплохие результаты.

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

Извините за цинизм, но единственная оценка труда работника - это деньги. Т.е. если будет з/п и премии, то значит ценят. :)

2 Lepsik
Большое спасибо за информацию. Извините, что только сейчас об этом говорю.

Mik Prokoshin Ярослав ТатаренкоНаписанные мною функции memset, memcpy и memmove превосходят аналогичные библиотеки по скорости на VC++ примерно в 4-6 раз.
Класс array превосходит примерно на 80%, но он еще не до конца профилирован. Так что фора, боюсь, мне не нужна. ;)
Честно скажу, что не озадачивался вопросом оценки подобных операций, но если вы так уверены в своих возможностях, Вам можно просто выставлять на продажу свои библиотеки системных функций. Хотя меня терзают смутные сомнения, что не все так просто (что Вы где-то выкинули "лишнюю" диагностику, проверки возможных вариантов и т.д.). Вот при широком распространении на разных программно-аппаратных платформах это и выяснилось бы. Или оно уже широко протестировано ?

Тестирование было произведено самым ненадежным методом: черный ящик. К сожалению у меня, да и в компании, нет средств и времени на серьезные методы тестирования. К величайшему сожалению...

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

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

Mik ProkoshinПодобные вещи неэффективны прежде всего в обслуживании. Сколько усилий надо для более-менее сложной выборки (анализа статистики) ? А далее сколько усилий надо будет для разбирания этих гор кода Вашим последователем, в случае Вашего увольнения ?

Сейчас вы рассматриваете проблему со стороны руководителя.

Mik Prokoshin
Цена - не в стоимости работы программиста, а в стоимости эксплуатации ! Если мы берем дешевый сервер и пытаемся его программировать на ассемблере, то наверняка будут вылазить всякие глюки железа и софта. С самописным софтом глюки (нестабильные) железа отлавливать - вообще проще застрелиться ! Далее - чем ниже уровень языка программирования, тем больше время на разработку+отладку+выше процент возможных последующих ошибок (не буду комментировать, это классика жанра, Вам Репликант сможет источников накидать :-). Соответственно, при росте общего объема программы, необходимо больше усилий на сопровождение.

Опять, же Вы рассматриваете все со стороны руководителя.
Теперь с моей стороны: у нас есть аппаратура, у меня есть задача и сроки сдачи. Остальное руководителя не интересует. Исходя из моей квалификации он исходит, что это вполне можно сделать.
В этой ситуации есть 3 выхода:
1. Выполнить задачу, используя готовые решения и увеличив смету затрат.
2. Выполнить задачу, используя собственные силы и незначительно увеличив смету.
3. Уволиться.

1-й вариант уже рассматривался до появления данной ветки. Осталось только 2 выхода.

Mik Prokoshin
Я, конечно сталкивался с примерно Вашей ситуацией на одном нашем загнивающем заводе. Там были измерения на двигателях на стендах. Короче, когда энтузиаст-программист уволился, найдя более денежную работу, дальнейшая разработка прекратилась, а потом и вовсе забросили то, что уже было наваяно, перейдя к обсуждению закупки полного программно-аппаратного комплекса стенда буржуйского производства весьма нехилой стоимости. Окончательного результата - не знаю.

Скорее всего они отказались от задачи или значительно упростили ее.

Mik Prokoshin
Короче, мое дело было лишь предложить вариант "как обычно делают". Не подходит - не надо. Идите своим путем.

см. выше

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