Есть ли что-либо подобное для дельфи ?

Здесь, конечно же ничего не сказано....
http://www.intel.com/cd/software/products/asmo-na/eng/294797.htm#features

KilkennyCat ©,
При всём уважении, Вы мой вопрос хоть прочли ?
Прямая цитата оттуда:
Intel® Threading Building Blocks (Intel® TBB) is an award winning C++ template library that abstracts threads to tasks to create reliable, portable and scalable parallel applications.
А мой вопрос заключался в следующем:
"Есть ли что-либо подобное для дельфи ?"

а... да. Приношу извинения. Я подумал, что именно сей продукт.

Неужели для Дельфи нет ничего, специально заточенного под многоядерные процессоры ? Это я спрашиваю завсегдатаев этого форума, всё-таки  мастера Дельфи. Понятно, что поддержку нужно ждать от Intel, но ведь и
"OpenMP (Open Multi-Processing) это набор директив компилятора, библиотечных процедур и переменных окружения, которые предназначены для программирования многопоточных приложений на многопроцессорных системах с разделяемой памятью на языках C, C++ и Fortran." - описание взято из http://ru.wikipedia.org/wiki/OpenMP, также подразумевает С, С++ и Fortran. Где поддержка мультипроцессорности в Delphi ?
Написал многопоточное приложение в Delphi, получил удручающие результаты - скорость обработки информации получилась гораздо меньше, нежели та же программа, написанная без разделения программы на потоки.
Или в Delphi так криво реализована многопоточность ? Сомневаюсь в этом.

Я на многих ядрах не игрался, но подозреваю, что автор как-то странно реализовал многопоточность. Ну, например, (я не подозреваю автора в таком деянии, а просто привожу пример того, как можно было бы снизить производительность введя потоки) если мы упихаем весь код метода Execute в Synchronize, то получим весь осмысленный код, выполняющийся в одном потоке + дополнительные расходы на переключение между несколькими дополнительными, что, конечно, даст дополнительные же тормоза.

TUser,
Что касается странности реализации - взял пример всеми уважаемого Марко Кенту и немножко переделал его под свою задачу. Логическая структура организации потоков осталась такой же, как и в оригинале у Кенту. Только работа, выполняемая в потоках изменилась. Что интересно, потоки никаким образом не пользуются никакими разделяемыми ресурсами - всю необходимую для потоков информацию подготавливаю заранее - считываю информацию из файлов, заполняю структуры данными и т.д.
Т.е. потоки фактически выполняют совершенно не связанную между собой работу.

Я бы конечно, привел исходник в студию, но смогу сделать это не раньше, чем завтра. Да ведь дело даже не в нём. Я уже почти решил свою задачу на С++. Тем более, что изначально в задании требовалось реализовать задачу именно на нём. Просто хотел ускорить выполнение программы, сначала взялся за "выглаживание" алгоритма обработки, затем вот подумал о распаралеливании.
Взяв простые примеры многопоточных программ на Дельфи, выполняющих, к примеру сортировку, я убедился, что никакого выигрыша не наблюдается, а наоборот, проигрыш, и серьёзный. Вообще, кто-нибудь в курсе, если использовать WinAPI (применительно к многопоточности, конечно), напрямую, есть ли выигрыш от его использования ?

> Subzero ©   (20.09.08 07:59) [6]
>
>

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

TUser,
Инфы не очень много, обрабатываются файлы размером под 20-30 Мб.
Сейчас многие жёсткие диски имеют буферы большего объёма :), так что это не критичное место совсем. Скорость чтения в тот же TStream несравнима с общим временем работы потоков.

> Subzero ©   (20.09.08 06:40) [4]


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

Я вот тоже сомневаюсь. Тем более, что Делфи тут вообще ни при чем. Потоками рулит ОС и не надо ей помогать в этом. Главное ей не мешать.

> Т.е. потоки фактически выполняют совершенно не связанную
> между собой работу.

Уверен на 100%?

> Subzero ©   (20.09.08 06:40) [4]
> Написал многопоточное приложение в Delphi, получил удручающие
> результаты - скорость обработки информации получилась гораздо
> меньше, нежели та же программа, написанная без разделения
> программы на потоки.

Не совсем понятно: это результаты выполнения программы на одноядерном или многоядерном процессоре?
А вобще ответ один: руки. Все в них дело.

> Subzero ©   (20.09.08 06:40) [4]
> Или в Delphi так криво реализована многопоточность ?

А дельфи тут вообще при чем? Вы вообще понимаете как потоки работают и кто ими рулит?

KSergey,
сомневайтесь лучше в своей компетенции.
DVM,

> Уверен на 100%?

Не уверен на 100%, и что это даёт ?
Пипец, ну и уровень ответов, я офигеваю...
Никто, кроме TUser ничего толкового даже спросить не может, не то, что дать конкретный ответ. Пипец, млин, мастера...

Потоками рулит ОС и не надо ей помогать в этом

Пацталом...
Точно, пипец, мастера.

А дельфи тут вообще при чем? Вы вообще понимаете как потоки работают и
кто ими рулит?

Нет, млин, не знаю нихрена, поэтому и задаю вопрос. Дельфи тут при том, что это её классом  я пользовался, когда описывал свои потоки.
Млин, где тут настоящие мастера? Или им просто сказать нечего, потому что реально нет ничего такого, сделанного для Дельфи, что реально помогало бы писать многопоточные приложения, и это удел только С++ и Фортрана ?

Забудьте Вы, мастера, про мою программу.
Я Вас спрашивал не ней, и не о том, насколько прямые у меня руки. ПИПЕЦ.
Вопрос в следующем:
Intel® Threading Building Blocks - есть ли что-либо подобное для Дельфи.

> Вообще, кто-нибудь в курсе, если использовать WinAPI (применительно
> к многопоточности, конечно), напрямую, есть ли выигрыш от
> его использования ?

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

> Или в Delphi так криво реализована многопоточность ?

И это тоже мне по барабану. :)

Прежде чем писать ответы - советую "мастерам" сходить по ссылке:
http://www.intel.com/cd/software/products/asmo-na/eng/294797.htm#features и ознакомиться с содержимым страницы, дабы не задавать мне ненужных вопросов.