BugTraq.Ru: шайтан код 3

шайтан код 3
16.12.11 18:57 // оригинал
Итак, при выборе версии ACML решили посмотреть на результаты вооруженным глазом. Расчет стационара давал разницу в десятки-сотни миллисекунд, что было не слишком показательно, так что я взял нестационар, который по сути представляет собой последовательный расчет нескольких временнЫх слоев, убрав тренажерную задержку между слоями. Некий оверхед приходится на перекачку данных, но это как раз добавляет тесту реалистичности.

Картина получилась забавной (результаты в минуты:секунды. На 60 слоях интеловская сборка в однопроцессорном варианте на моем i7 показала 1:15, в многопроцессорном - 1:20. При этом многопроцессорная грузила процессор сильнее процентов на 10, загружая все, включая виртуальные процессоры от HT; однопроцессорная - только основные 4 ядра. Возможно, в многопроцессорном варианте больше времени тратилось на стартовое раскочегаривание, а заканчивалось все слишком быстро (каждый расчет шел индивидуально). А может интел слишком полагался на HT, который в этом коде не давал выигрыша.

PGI показал более разумные и понятные результаты: 1:10 в многопроцессорной сборке и 1:30 в однопроцессорной. Картина загрузки ядер при этом больше напоминала интеловскую однопроцессорную. Итого по результатам вчистую выиграла многопроцессорная PGI-сборка, ее и включили в дистрибутив.

А вот дальше произошло то, что я пока вообще не понимаю. Разработчик расчетного модуля у нас человек упорный, он взял фортрановские исходники используемых библиотечных функций, перетащил их на C++ и собрал (со стандартной оптимизацией, без всяких SSE и многопоточности). Сборка с полученной функцией считает у меня все ту же задачу за 0:55, везя PGI MP 15 секунд и уделывая работающий в тех же условиях PGI SP вообще в полтора раза. Причины этого - полнейшая загадка для меня. Как, впрочем, и то, что ж за код у нас там был раньше (тоже прошедший этапы большого пути от фортрана к плюсам через ратфор), который мимоходом съедал поколения 3-4 развития процессоров.

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

обсудить | все отзывы (0) | обсудить в LJ [1917]

назад « » вперед

последние записи

песчаное // 13.03.24 18:05
макоудаленное // 29.01.24 23:10
разнонедельное // 07.12.23 15:09
qtменюшное // 29.09.23 23:47
неестественноинтеллектуальное // 29.09.23 16:50
основательное // 18.09.23 00:15
отпускное // 06.08.23 00:26
вчерашнезавтрашнее // 02.07.23 15:25
позитивное // 27.06.23 13:05
тейлскейлное // 18.04.23 20:43