96 вычислительных ядер и оптимизация кода муравьиного алгоритма поиска маршрутов

[LooMaclin]

Спасибо за статью. Где можно изучить исходный код описанного алгоритма и соответствующих оптимизаций?

[easyman]

Свежая информация про муравьёв (не про IT)
Вкратце, они шаги считают.

[masha_kupina]

Спасибо! A со сторонними GPU ваш профилировщик так же эффективно дружит, как с родными процами? Не планируете и такую возможность обозреть (с radeon rx480 например)? Присматриваюсь что нить приобресть для расчетов, но ваши системы всё таки дороговаты для домашней лаборатории. Вот пытаюсь прикинуть по железу и инструментам, что к чему и как эффективно можно прикрутить.

[Nikobraz]

Огромнейшее спасибо за статью. Буквально на днях голову ломал почему некоторые сервера плохо себя показывают в многопоточности, особенно с HT. Опытные сисадмины сказали, что производительность на 1 ядро решает(т.е. копи на E5-2690). Вы показали, что это совсем не так. Теперь есть куда копать и пример как делать.

[VaalKIA]

192 ядра дают ускорение в 5 раз и это вы назваете: «Полагаем, это достойный результат, который стоит усилий»?
Какой-то маркетинговый булшит.
Достаточно посмотреть на предпоследний график, что бы понять, что ваша программа и алгоритм вообще не масштабируются по ядрам. Цифры:
1 = 4071
2 = 1577
4 = 977

[VaalKIA]

Не успел отредактировать, далее увеличения фактически не происходит

[masha_kupina]

дык это прирост к базе в 24 ядра (48 логических ядер). То есть увеличиваем железную часть в 4 раза, и посредством VTune получаем прирост производительности в 5,3 раз (против 1,79 без оного)

[masha_kupina]

1 = 4071
2 = 1577
4 = 977

Как понимаю, во всех этих случаях работают все 192 ядра, но с разным распределением потоков по процессам ( первом и худшем случае — 192 потока в одном процессе)) Эта диаграмма показывает потенциал программной оптимизации, а не железной многоядерности.

[old_bear]

за график не от нуля (среди всех остальных графиков от нуля) надо бить по рукам линейкой

[Deosis]

На графике видно что в конце «месяца» все встают в очередь и ждут.
Как вам такой вариант:
Первый раз дочерние потоки выполняют рандомное количество работы.
При каждой неудачной попытке передать данные, дочерний поток выполняет небольшое количество работы.
После успешной попытки дочерний поток выполняет столько работы, чтобы за это время остальные дочерние потоки по очереди передали данные. (Количество можно установить статически или динамически на основе количества попыток передать данные)
Тогда данные будут идти равномерно, без всплесков. Большинство блокировок должны стать успешными.

[phprus]

Скажите, пожалуйста, а что в этом алгоритме делает постоянное создание новых строк (std::string), из-за чего в списке Top Hotspots конструктор std::string::string оказался самой тяжелой операцией?