[erlang-questions] Strange multi-core result on windows.

[Tony Rogvall]

Interesting reading, please post a link to where to find the code and data examples to backup this findings, and
allow for others to repeat your experiments.
/Tony

On 27 nov 2011, at 00:41, Ian wrote:

> HI all,
> 
> I have written a program in Erlang, that has 4 async processes in "string of pearls" formation. The results were surprisingly quick, so I threw a huge input file at it to see what would happen.
> 
> Expected one process (the 2nd) to require more cpu than the others. As the limiting factor it would max out one core to 100%. The rest would be  less, constant and approx equal.  But this isn't what happened.
> 
> Three cores were loaded about 40-50%. The 4th core was left at virtually idle (2%).  Job ran in 25 seconds, average load about 32%.
> 
> So I moved the input and output files to a ram disk. And got much the same result. It ran in 22 seconds, and loaded 3 cores, one 50% and varying, the others 30% or so, Overall 30%.
> 
> Then I tried with +A 5 and the RAM drive. Now it loaded one core 60 to 90%, and a a second about 40-60%. The other two cores flickered a little and settled back to background! Job ran in 23 seconds, average load about 30%.
> 
> So I guess that disk was not limiting the speed. But what was? I never got the load over 35%.
> 
> Can some kind person please explain the scheduling algorithm in the VM, and explain these results. They seem very odd to me.
> 
> Thanks
> 
> Ian
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111127/bdd1dd01/attachment.htm>