Killing me softly with ... primes ...

[stitch]

я , честно, хз ,что у тя за язык и как ему линкером можно параллельность регулировать

Haskell

Concurrency - HaskellWiki

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

Я же 'top' и показал в предидущем посте.

поставь лучше в цикле компиляцию чего-нить типа линукс ядра или потяжелее . C make -j , ага возможно, придется потом жестко ребутить сервер

Не, ребутить не придется, просто медленее буде для каждой отдельной target. Я обычно даю -j с аргументом равным количеству CPU cores. Если без ничего, то это вроде как unlimited target execution in parallel.

[the_alexx]

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

у мня , было дело ,какой-то линукс жестко зависал на I/O , когда я ядро с make -j без ограничений захотел построить ..

[stitch]

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

у мня , было дело ,какой-то линукс жестко зависал на I/O , когда я ядро с make -j без ограничений захотел построить ..

Да все там показывает Там же все 16 cores ..
Зачем мне остальной список? Там остальные процессы занимают insignificant load в сотых и десятых. Ну вот только для одного процесса, если что ....
Почти равномерное распределение по ядрам.

[stitch@taipan ~]$ top -p 31946

top - 18:24:40 up 4 days, 2:31, 5 users, load average: 6.81, 6.35, 6.12
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
%Cpu0 : 10.7 us, 5.4 sy, 0.0 ni, 82.9 id, 0.0 wa, 0.0 hi, 1.0 si, 0.0 st
%Cpu1 : 19.8 us, 8.2 sy, 0.0 ni, 72.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 21.0 us, 5.5 sy, 0.0 ni, 73.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 28.3 us, 8.9 sy, 0.0 ni, 62.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu4 : 12.5 us, 5.1 sy, 0.0 ni, 82.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu5 : 52.7 us, 22.1 sy, 0.0 ni, 25.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu6 : 27.9 us, 11.2 sy, 0.0 ni, 60.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu7 : 33.9 us, 8.6 sy, 0.0 ni, 57.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu8 : 20.5 us, 7.4 sy, 0.0 ni, 72.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu9 : 31.2 us, 9.0 sy, 0.0 ni, 59.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu10 : 23.8 us, 7.9 sy, 0.0 ni, 68.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu11 : 23.7 us, 10.1 sy, 0.0 ni, 66.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu12 : 17.5 us, 7.4 sy, 0.0 ni, 75.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu13 : 31.8 us, 9.3 sy, 0.0 ni, 58.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu14 : 26.7 us, 7.6 sy, 0.0 ni, 65.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu15 : 22.0 us, 6.8 sy, 0.0 ni, 71.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 6097948 total, 5759000 used, 338948 free, 4328 buffers
KiB Swap: 0 total, 0 used, 0 free, 3913968 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31946 stitch 20 0 1261m 21m 1104 R 597 0.4 9372:59 primes

Это load только одного процесса показан на все 16 ядер.

Можно то же самое посмотреть с pidstat.

[the_alexx]

вопрос-то - у тебя один тред в топе показан или 16 ? Если разрешить топу показывать треды ?

[stitch]

вопрос-то - у тебя один тред в топе показан или 16 ? Если разрешить топу показывать треды ?

Ну вот threaded view ..
Только не пойму почему 18 threads ...

top - 11:40:08 up 4 days, 19:47, 5 users, load average: 6.97, 7.19, 6.40
Threads: 18 total, 2 running, 16 sleeping, 0 stopped, 0 zombie
%Cpu(s): 34.6 us, 4.0 sy, 0.0 ni, 61.4 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem: 6097948 total, 5319352 used, 778596 free, 4328 buffers
KiB Swap: 0 total, 0 used, 0 free, 3981284 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31946 stitch 20 0 1261m 21m 1104 R 85.2 0.4 2389:29 primes
31963 stitch 20 0 1261m 21m 1104 R 51.9 0.4 1187:29 primes
31947 stitch 20 0 1261m 21m 1104 S 46.3 0.4 1143:22 primes
31948 stitch 20 0 1261m 21m 1104 S 42.3 0.4 1100:44 primes
31951 stitch 20 0 1261m 21m 1104 S 39.6 0.4 950:05.94 primes
31949 stitch 20 0 1261m 21m 1104 S 39.3 0.4 1050:10 primes
31952 stitch 20 0 1261m 21m 1104 S 38.6 0.4 900:11.19 primes
31953 stitch 20 0 1261m 21m 1104 S 38.3 0.4 845:52.66 primes
31954 stitch 20 0 1261m 21m 1104 S 38.3 0.4 787:45.77 primes
31950 stitch 20 0 1261m 21m 1104 S 37.6 0.4 997:12.11 primes
31955 stitch 20 0 1261m 21m 1104 S 33.6 0.4 734:46.40 primes
31958 stitch 20 0 1261m 21m 1104 S 33.6 0.4 627:28.70 primes
31957 stitch 20 0 1261m 21m 1104 S 30.3 0.4 651:35.75 primes
31956 stitch 20 0 1261m 21m 1104 S 28.6 0.4 686:07.81 primes
31959 stitch 20 0 1261m 21m 1104 S 24.3 0.4 609:39.50 primes
31960 stitch 20 0 1261m 21m 1104 S 22.3 0.4 599:35.79 primes
31961 stitch 20 0 1261m 21m 1104 S 0.0 0.4 0:00.00 primes
31962 stitch 20 0 1261m 21m 1104 S 0.0 0.4 0:00.00 primes

Если использовать htop, то показывает все threads по умолчанию и в красках.

[stitch]

должен на параллельных задачах показать столько экземпляров процесса, скоко ядер задействовано.

Я, если честно, никак не пойму, что ты имеешь в виду под "параллельные задачки"?
Я конечно не программер, но мне кажется, что ты путаешь parallelism and concurrency.

Concurrency is when you *explicitly* define threads in a program and structure your code appropriately. Ну это как я себе понимаю. Извини за иностранщину.
Concurrent program can happily run on a single core. Concurrency is NOT about executing in parallel, it is about independent thread control, shared resources management and independent I/O. Concurrent programs can execute sequentially as well as in parallel.

В то время как parallelism is all about spreading work load of a process across multiple cores. It is all about running a certain task faster on multi-core then it would otherwise run on a single core. That's it. Nothing less, nothing more.

Ну вот как-то так... Програмеры поправят если что.
Кстати, интересная темa сама по себе.

Так вот, для моей маленькой задачки не надо explicit thread definition and structure вsего лиш для того чтобы работало на всех ядрах. Мне всего лишь нужен parallelism, а не concurrency.

[the_alexx]

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

ты можешь explicitly определить треды в коде - они , скорее всего, будут раскиданы по разным ядрам, ну и в некоторых пределах можно привязку к конкретному ядру контролировать. это тоже будет параллелизм типа.

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


Но не каждую задачу можно распараллелить, я вот про что ..

поэтому интересно, как твой хаскелл параллелит поиск праймов. там же зависимости есть следующего результата от предыдущего ..

кстати, только один поток грузит проц на 85% , и один на 51% , остальные - на 30-40 так ?

два нифиганеделающих - это контрольные , стартап-клинап какой-нить .

[23b40]

а потом в Мельбурне туннели закрывают

я кажется знаю чаво регулирует сервер топикстартера...

[stitch]

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

Хорошо. Только нам не нужно explicit thread definition в самой задачке.
В императивных языках не всегда можно делать parallelism без concurrency. Или даже совсем нельзя, наверно ... В функциональных языках - можно.
Поэтому и спросил если видишь разницу.

ты можешь explicitly определить треды в коде - они , скорее всего, будут раскиданы по разным ядрам, ну и в некоторых пределах можно привязку к конкретному ядру контролировать. это тоже будет параллелизм типа.

В том то и дело, что если код с explicitly defined threads ранит на одном ядре, то это concurrency, но не parallelism.

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

Да. Поэтому и надо было перелинковать с threaded run-time library.

Но не каждую задачу можно распараллелить, я вот про что ..

поэтому интересно, как твой хаскелл параллелит поиск праймов. там же зависимости есть следующего результата от предыдущего ..

Почему? Mapping a function over a list can be parallelised.
Допустим:
newList = map (*2) [1,2,3,4]
Получаем: [2,4,6,8]

Тебе ведь не надо делать это последовательно, так ведь?
Ты это вполне можешь делать блоками по 4, скажем ...
Тогда в верхнем примере, при наличии четырех ядер, умножение будет происходить параллельно.

В этой задачке это происходит два раза.
Первый раз при факторизации и второй раз при проходе по листу с факторами.
Просто у меня там используются list comprehensions, которые можно свести к фильтру по листам, который, в свою очередь, можно назвать conditional map.

То, что это происходит именно так я не уверен Это лишь мои доводы и я могу быть неправ.

Я попробую упростить задачку, разобить на составные и запараллелировать explicitly. Если время будет и желание ...

кстати, только один поток грузит проц на 85% , и один на 51% , остальные - на 30-40 так ?

два нифиганеделающих - это контрольные , стартап-клинап какой-нить .

Да, в динамике оно конечно меняется, но на один thread нагрузка всегда больше.
А два пустых это скорее всего garbage collector и еще че-нить ...

[the_alexx]

То, что это происходит именно так я не уверен Это лишь мои доводы и я могу быть неправ.

Я попробую упростить задачку, разобить на составные и запараллелировать explicitly. Если время будет и желание ...

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

вот это можно запараллелить - делить число одновременно на 16 чисел на 16ти ядрах.

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

[stitch]

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

Да хоть Haskell хоть C, Какая разница ...
Любой логический алгоритм можно воплотить в любом языке, поэтому тоже самое, что я привел в первом посту можно переписать в С, только длинее получится. Haskell такие вещи просто короче делает, а так разницы нет. Можно было вообще все одной строкой сделать.

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

Алгоритмов нахождения праймов множество. Тот, что использовал я - детский, почти то же, что ты привел выше.
У меня, как ты видел с кода, алгоритм такой:
1. Найти все факторы числа и положить их в лист.
2. Сравнить лист с факторами с [0,1]. Если True значить Prime.
3. Пройтись по листу от 2 до бесконечности и отпринтовать праймы.

Самый быстрый алгоритм называется Sieve of Eratosthenes и работает он совсем по другому.

вот это можно запараллелить - делить число одновременно на 16 чисел на 16ти ядрах.

Так это и запараллелено. Все хождения по листам запараллелины.

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

Почему это нельзя? У меня есть функция isPrime, которая возвращает true если аргумент является праймом. Потом я шагаю по бесконечному листу с этой функцией и если число является праймом, то принтую его, а если нет иду дальше. Я могу тестировать сразу несколько последовательных чисел, скажем взять первый блок [2,3,4,5] и протестировать параллельно, потом следующий [6,7,8,9] ... и так далее. Что, в общем-то, и происходит в моем случае. Плюс, факторизация тоже легко параллелится.

[the_alexx]

. Я могу тестировать сразу несколько последовательных чисел, скажем взять первый блок [2,3,4,5] и протестировать параллельно, потом следующий [6,7,8,9] ... и так далее. Что, в общем-то, и происходит в моем случае. Плюс, факторизация тоже легко параллелится.

у тя для каждого числа своя независимая факторизация ? тогда да , можно . хотя и неоптимально ..

в isPrime ты делишь на все числа от 1 до n ? достаточно было бы поделить на все уже найденные праймы. только тут как раз нюанс и вылезает, если для этих праймов один общий список использовать.


да, и решето не работает для бесконечных последовательностей