Page 2 of 2

Re: Multicore Detection

Posted: Sun Jun 13, 2010 5:04 am
by hyatt
I think the issue he is talking about is having to pass a pointer around to the various split blocks to reference local data. I'd much rather do that than duplicate the code however.

Re: Multicore Detection

Posted: Sun Jun 13, 2010 5:07 am
by Sentinel
hyatt wrote:I think the issue he is talking about is having to pass a pointer around to the various split blocks to reference local data. I'd much rather do that than duplicate the code however.
Yes, that's the point. And duplicating the code for just 5 elo has no sense at all.

Re: Multicore Detection

Posted: Sun Jun 13, 2010 6:45 am
by kingliveson
Sentinel wrote:
hyatt wrote:I think the issue he is talking about is having to pass a pointer around to the various split blocks to reference local data. I'd much rather do that than duplicate the code however.
Yes, that's the point. And duplicating the code for just 5 elo has no sense at all.
Personally I don't see even 5 elo being gained by code duplication here. If that was the case then one might say it's worth it. Should be interesting once the source is released as promised. Take a look at single CPU Robbolitos and SMP Ivanhoe (set to single thread) speed test:

Image

Re: Multicore Detection

Posted: Sun Jun 13, 2010 6:55 am
by Sentinel
kingliveson wrote:Personally I don't see even 5 elo being gained by code duplication here. If that was the case then one might say it's worth it. Should be interesting once the source is released as promised. Take a look at single CPU Robbolitos and SMP Ivanhoe (set to single thread) speed test:
That's because you are comparing apples and oranges. Code compiled by different compilers and different ppl.
Both g3 and 009 are VC++ 2008 compile (without any special optimization). Ivanhoe is Intel PGO compile. Plus, as I mentioned earlier, difference in 64bit compiles is much smaller than in 32 bit (due to different pointer implementation). So 5 ELO is for 32bit only.