> На одном проце по определению однопоточный вариант будет выигрывать.
Смотря какая природа у этого варианта. У меня сейчас два потока работают - один грузит данные из базы - второй эти данные обрабатывает. У этих потоков одна точка соприкосновения - буфер обмена, в которых каждый проводит не очень много времени. пока первый простаивает (ждет отклика от БД или сигнала "есть место в буфере") - второй по полной работает. если второй "заснул" (например ждет завершения операций с файлом, куда выгружаются данные), может кто-то еще работать. я предполагал, что сможет работать параллельный "комбинатор" проблема в том, что первый успевает насытить буфер с исходными данными под завязку, а второй пашет как ненормальный что бы этот буфер освободить, но очень редко когда его опустошает. Самое что неприятное, у меня по середине какого-то изменения почти удалось достигнуть желаемого. Но когда все доделал - однопоточный вариант начал работать в два раза быстрее, а многопоточный все также клинит, хотя в целом он тоже стал работать быстрее, но видно что не за счет устранения конфликтов. Траблы где то на пути регистрации сгенерированных комбинаций в индексе (он общий для всех потоков "комбинирования") и хотя я там и "секционированные" блокировки прикрутил и у каждого потока свой локальный кэш этого индекса - все равно где-то потоки схлестываются и системное время процесса подскакивает до 30%. Профайлера у меня нету, так что пока только и остается что разводить руками. В приципе, у меня есть идеи как хотя бы выяснить где именно тормоза - я еще пока понимаю как работает моя игрушка. Но пока достигнутые результаты меня устраиват и нужно наконец начать двигаться вперед. Коваленко Дмитрий.
