ScaleMM. Кто-нибудь использует?

← →
Омлет © (2011-11-30 12:26) [0]

It is faster (4x!) and scales better than FastMM. Also faster (3x) than TopMM, but equal scaling.
http://code.google.com/p/scalemm/

← →
DVM © (2011-11-30 12:32) [1]

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

← →
Jeer © (2011-11-30 12:58) [2]

Угу. :)

← →
Jeer © (2011-11-30 13:02) [3]

Стоит давно стандартно :)

← →
Омлет © (2011-11-30 13:07) [4]

> Jeer © (30.11.11 13:02) [3]

На продакшене? Какие-то проблемы/замечания есть? Стоит поверх FastMM или вместо?

← →
DVM © (2011-11-30 13:30) [5]

> Jeer © (30.11.11 13:02) [3]
> Стоит давно стандартно :)

И стабильно работает?

Я вот щас попробовал в одной своей программе - вылетело AccessViolation

Еще попробовал TopMEM - работает вроде нормально, но код его надо править (там есть пара мест PAnsiChar -> PChar).

Ну и оба менеджера содержат ассемблерные вставки (TopMEM совсем чуть), под x64 не заработают.

← →
DVM © (2011-11-30 13:30) [6]

> Омлет © (30.11.11 13:07) [4]

> Стоит поверх FastMM или вместо?

Что значит поверх? Это как?

← →
Омлет © (2011-11-30 14:01) [7]

> Что значит поверх? Это как?

uses FastMM4, SynScaleMM,

http://synopse.info/forum/viewtopic.php?pid=892#p892
SynScaleMM over FastMM4

← →
DVM © (2011-11-30 14:10) [8]

> Омлет © (30.11.11 14:01) [7]

SynScaleMM это же другой менеджер, не тот, что в [0]

← →
Омлет © (2011-11-30 14:24) [9]

> SynScaleMM это же другой менеджер

Тот самый, просто имя модуля другое.
В общем, как я понял, он полезен для многопоточных приложений.

← →
Омлет © (2011-11-30 14:31) [10]

А еще говорят, в FastMM5 будет нормальная поддержка многопоточности.

← →
Омлет © (2011-11-30 14:35) [11]

> Омлет © (30.11.11 14:24) [9]
> > SynScaleMM это же другой менеджерТот самый, просто имя
> модуля другое.

Нет, все-таки не тот самый. Это форк ScaleMM
http://synopse.info/forum/viewtopic.php?pid=771#p771

← →
Jeer © (2011-11-30 14:41) [12]

Поскольку я дальше D7 не ушел, то и стоит в ней после FastMM4.
Использую для многопоточных, т.е. не слишком часто.
Особых проблем не заметил.

← →
Омлет © (2011-11-30 14:42) [13]

> Омлет © (30.11.11 14:35) [11]

Был ScaleMM, потом A.Bouchez сделал форк под названием SynScaleMM, который в итоге вылился в ScaleMM2.

← →
Сергей М. © (2011-11-30 15:35) [14]

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

Полагаю, там заявленная фора в производительности покажет себя лучшим образом ...

← →
Anatoly Podgoretsky © (2011-11-30 15:40) [15]

> DVM (30.11.2011 13:30:05) [5]

Короче могила

← →
Jeer © (2011-11-30 16:00) [16]

> Сергей М. © (30.11.11 15:35) [14]
>
> Надо бы на приличном мультипоточном движке не самой простой
> нейросети (самоорганизующейся - самое то) это чудо опробовать
> ..

Как раз экспериментировал на нейросетке от BaseGroup.
Имело практический выход в системе раскроя 2D-материалов.

← →
Сергей М. © (2011-11-30 16:04) [17]

> на нейросетке от BaseGroup.

Это которая в дельфях представлена TNeuralBase ?

← →
Jeer © (2011-11-30 16:10) [18]

Типа, да - там несколько вариантов сетей: Хопфилд, back* ...

← →
Сергей М. © (2011-11-30 16:25) [19]

Несерьезно, Серёг) ..

В классе TNeuralBase ни мультипоточностью ни мультиядерностью даже не пахнет - весь компьтинг там выполняется в один поток и при напрочь отсутствующей даже элементарной оптимизации.

Я вот сейчас довылизываю собственный дельфийский порт этой BP-сети
http://www.codeproject.com/KB/librar/NeuralNetRecognition.aspx?display=Print

Там заява на мультипоточноть имеется, но довольно убогая и не без странностей.

На стареньком двуядерном Атлоне 3000 при нормальном приоритете процесса и наивысшем приорирете двух рабочих нейротредов в нем (по одному на ядро) одна эпоха в 60000 полных циклов (прямое + обратное распространение) у меня с FastMM4 выполняются примерно за 35 мин.

Я к тому что если ScaleMem покажет хотя бы двукратный прирост скорости при тех же условиях, то полагаю что есть ощутимый резон поставить его на боевое дежурство)

← →
Jeer © (2011-11-30 16:33) [20]

> Сергей М. © (30.11.11 16:25) [19]
>
> Несерьезно, Серёг) ..

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

← →
Сергей М. © (2011-11-30 16:44) [21]

> Jeer © (30.11.11 16:33) [20]

А как с дельфийскими FWAIT поступал в порте ?
Не выкорчевывал в фин.релизе ? Или не стал заморачиваться ?

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

← →
Jeer © (2011-11-30 17:36) [22]

> А как с дельфийскими FWAIT поступал в порте

Дык давно выдраны в своей библиотеке FPU. :)
Нафик они нужны :)
Хотя и не думаю, что от них что-то заметное можно обнаружить.

> Хотя и не думаю, что от них что-то заметное можно обнаружить.

Есть у меня своя библиотека для обработки изображений. Есть там процедура перевод массива real в integer. Когда round заменил на round без FWait прирост был колоссальным. Не помню во сколько раз, но много.

По поводу менеджера памяти. У меня свой чисто на дельфе, по скорости не оптимизировал. Вообще делал как можно проще. Но выделяет у меня гораздо быстрее стандартного, но вот освобождение памяти у меня было медленное.
Так что его при любом желании обгонишь.

> в своей библиотеке FPU

С ними-то как раз вопросов нет)

> не думаю, что от них что-то заметное можно обнаружить

По такту на каждый FWAIT - это ощутимо заметно на бешеного объема вычислениях, характерных для нейросетей.. да и не только для них)

> По такту на каждый FWAIT - это ощутимо заметно на бешеного
> объема вычислениях, характерных для нейросетей.

Я пошел, может быть, несколько по иному пути - оптимизация нагрузки потоков по вычислениям.
Смысл в том, что в несимметричных потоковых вычислениях и при необходимости синхронизации потоков на очередном слое ( а это факт: результат слоя - есть приход к консенсусу всех вычислений в нем ), приходится перераспределять вычислительную нагрузку по потокам на "следующем" шаге - иначе попадаем в элементарную случайность и очень плохое время в общем.

P.S.
Где-то у меня валяется тестовый проект - там хорошо видна результативность такого подхода. Ну и есть варианты с менеджерами.
Если найду и откомпилю - выложу.

Там была сделана интересная графическая интерпретация процесса распространения вычислений по потокам и слоям.

> результат слоя - есть приход к консенсусу всех вычислений
> в нем

Не подлежит сомнению.

> перераспределять вычислительную нагрузку по потокам на "следующем"
> шаге

Что ним подразумевается - следующий слой ?

Если "жестко" - следующий слой запускается после завершения предыдущего, возможны более "мягкие" решения.
Например, если отставание между слоями превышает некое среднее ( или заданное ) - допускается запускать (все дискретно с шагом) следующий слой на основании X% завершения предыдущего. Это работает.

Слои - многослойная нейросеть. Слои предварительно определены по функционалу создателем системы. Отличаются ( группируются ) по "траектории" процесса вычислений.
"Траектория" - воображаемая кривая положения точки вычислений в нейросети по мере достижения результата.

> допускается запускать (все дискретно с шагом) следующий
> слой на основании X% завершения предыдущего. Это работает

В Хопфилде и в BP - наверно, соглашусь. Хотя, полагаю, это ощутимо усложняет логику изменения LR и LM, что не лучшим образом сказывается на сквозной производительности обучающего алгоритма.

За Кохонена и иже с ним вообще не возьмусь судить - не пробовал ..

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

Поэтому, пока я не получу для конкретного заказа удовлетворяющего меня результата, он в "боевом" режиме работать не будет.

P.S.
До конца этого года много текущей работы, а с января хочу возродить этот функционал (адаптируемая самообучающаяся сеть BP) применительно к моей OLAP-системе РИАС (реагирование н-сети на "конфликты" в динамике социо-экономических показателей)

Ладно)
Будет январь, будет хлеб - будет и песня)

> Будет январь, будет хлеб - будет и песня)

Эт точно. Рад был потрындеть с тобой :)

← →
RTFM (2011-11-30 23:13) [32]

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=871366&msg=11088364

ScaleMM. Кто-нибудь использует? Найти похожие ветки