информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Где водятся OGRыЗа кого нас держат?Сетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Число обнародованных уязвимостей... 
 Последний второй Python 
 Microsoft предупредила о двух незакрытых... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / блог / архив / 2011
АРХИВ
архив
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004
2003
2002
archive





шайтан код 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 [1027]
назад «  » вперед

последние записи
викиисключительное // 20.05.20 21:20
гуглемитное-2 // 14.04.20 16:01
гуглемитное // 10.04.20 12:12
микрофонное // 27.03.20 17:49
звуковое // 20.03.20 18:50
каникулярное // 27.01.20 18:13
датское // 25.01.20 13:15
мтснороуминговое // 11.09.19 12:35
бунтороботное // 11.07.19 22:17
асусноапгрейдное // 23.06.19 22:29


авто венгрия вырвиглаз германия глюки греция гуглемап драйверы египет железки журнализм империя добра испания италия кино кипр клоуны книги криворучки оспорт португалия программизм сайт софт стрим студень турция уродцы фото франция цацки чехия читалки android bq e51 eeepc from facebook hd2 hpc htc ipad iphone onlime vista windows 10 windows 7 windows 8 yota



Rambler's Top100
Рейтинг@Mail.ru



  Copyright © 2001-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach