Komodo 5.1 x64 4CPU @ CEGT

[Modern Times]

900 games are played for the 40/4 so far:
http://cegt.siteboard.eu/f6t824-testing ... -4cpu.html

Best wishes,
G.S.

Thanks - so the gain from Komodo CCT x64 1CPU to Komodo 5.1 x64 4CPU shows as +70 Elo ?

[Don]

900 games are played for the 40/4 so far:
http://cegt.siteboard.eu/f6t824-testing ... -4cpu.html

Best wishes,
G.S.

Thanks - so the gain from Komodo CCT x64 1CPU to Komodo 5.1 x64 4CPU shows as +70 Elo ?

Komodo CCT is a stronger program, so this is not a very meaningful comparison unless you are using it decide whether to upgrade to MP. But we revealed long before release that Komodo 5.1 would be weaker than CCT.

Don

[ThatsIt]

Thanks - so the gain from Komodo CCT x64 1CPU to Komodo 5.1 x64 4CPU shows as +70 Elo ?

Hi Ray !

Yes, + 70 at the moment, but more important + 110 compared to Komodo 5.0 x64.

Best wishes,
G.S.
(CEGT member)

[beram]

900 games are played for the 40/4 so far:
http://cegt.siteboard.eu/f6t824-testing ... -4cpu.html

Best wishes,
G.S.

Thanks - so the gain from Komodo CCT x64 1CPU to Komodo 5.1 x64 4CPU shows as +70 Elo ?

Komodo CCT is a stronger program, so this is not a very meaningful comparison unless you are using it decide whether to upgrade to MP. But we revealed long before release that Komodo 5.1 would be weaker than CCT.

Don

I don't think that there are many (or if any) users who still prefer to play with just 1CPU.
So I think that +70 (or +110) for Komodo 5.1 MP is very meaningfull

[Modern Times]

900 games are played for the 40/4 so far:
http://cegt.siteboard.eu/f6t824-testing ... -4cpu.html

Best wishes,
G.S.

Thanks - so the gain from Komodo CCT x64 1CPU to Komodo 5.1 x64 4CPU shows as +70 Elo ?

Komodo CCT is a stronger program, so this is not a very meaningful comparison unless you are using it decide whether to upgrade to MP. But we revealed long before release that Komodo 5.1 would be weaker than CCT.

Don

"unless you are using it decide whether to upgrade to MP"


Yes, that was the point. A decision lots of customers might be wanting to make. +70 Elo is very useful.

[Don]

900 games are played for the 40/4 so far:
http://cegt.siteboard.eu/f6t824-testing ... -4cpu.html

Best wishes,
G.S.

Thanks - so the gain from Komodo CCT x64 1CPU to Komodo 5.1 x64 4CPU shows as +70 Elo ?

Komodo CCT is a stronger program, so this is not a very meaningful comparison unless you are using it decide whether to upgrade to MP. But we revealed long before release that Komodo 5.1 would be weaker than CCT.

Don

"unless you are using it decide whether to upgrade to MP"


Yes, that was the point. A decision lots of customers might be wanting to make. +70 Elo is very useful.

And of course 70 ELO is a big win. Our goal before release is that Komodo 5.1 MP should perform AT LEAST a few ELO better on 2 cores that Komodo CCT does on 1 core - and as it turns out it's not even a close call, so if you really like Komodo and want to upgrade it's strength then even Komodo 5.1 MP on 2 cores will be a big win.

Don

[Werewolf]

900 games are played for the 40/4 so far:
http://cegt.siteboard.eu/f6t824-testing ... -4cpu.html

Best wishes,
G.S.

Thanks - so the gain from Komodo CCT x64 1CPU to Komodo 5.1 x64 4CPU shows as +70 Elo ?

Komodo CCT is a stronger program, so this is not a very meaningful comparison unless you are using it decide whether to upgrade to MP. But we revealed long before release that Komodo 5.1 would be weaker than CCT.

Don

"unless you are using it decide whether to upgrade to MP"


Yes, that was the point. A decision lots of customers might be wanting to make. +70 Elo is very useful.

And of course 70 ELO is a big win. Our goal before release is that Komodo 5.1 MP should perform AT LEAST a few ELO better on 2 cores that Komodo CCT does on 1 core - and as it turns out it's not even a close call, so if you really like Komodo and want to upgrade it's strength then even Komodo 5.1 MP on 2 cores will be a big win.

Don

Just so I've understood correctly: The ONLY difference between Komodo CCT & 5.1 on one core is speed? So the MP implementation slowed the engine down a bit?

Now that MP is up & running do you have a target date for the next release? Will it be a new purchase or part of the 5.x series?

Thanks.

[Don]

900 games are played for the 40/4 so far:
http://cegt.siteboard.eu/f6t824-testing ... -4cpu.html

Best wishes,
G.S.

Thanks - so the gain from Komodo CCT x64 1CPU to Komodo 5.1 x64 4CPU shows as +70 Elo ?

Komodo CCT is a stronger program, so this is not a very meaningful comparison unless you are using it decide whether to upgrade to MP. But we revealed long before release that Komodo 5.1 would be weaker than CCT.

Don

"unless you are using it decide whether to upgrade to MP"


Yes, that was the point. A decision lots of customers might be wanting to make. +70 Elo is very useful.

And of course 70 ELO is a big win. Our goal before release is that Komodo 5.1 MP should perform AT LEAST a few ELO better on 2 cores that Komodo CCT does on 1 core - and as it turns out it's not even a close call, so if you really like Komodo and want to upgrade it's strength then even Komodo 5.1 MP on 2 cores will be a big win.

Don

Just so I've understood correctly: The ONLY difference between Komodo CCT & 5.1 on one core is speed? So the MP implementation slowed the engine down a bit?

No, it's a different code base altogether with most of komodo CCT stuff ported over but it's not identical.

If you only care about single core performance, Komodo 5.1 is a downgrade - and that is what you need to know as a buyer. If you have CCT and a quad and 70 ELO is not enough of an upgrade for you, then don't buy it.

Now that MP is up & running do you have a target date for the next release? Will it be a new purchase or part of the 5.x series?

Thanks.

The next release is going to be a bug fix release first of all. The book no longer works in Komodo. In windows there is also a minor memory leak and it appears to be in the C++11 libraries as it does not happen on any other platform. The workaround if you are a tester is to start the engine between games, which all testers should do anyway. In Linux the timing does not work right on modern distributions such as Ubuntu 13.04 so I'm trying to fix that too. Should be within a couple of days.

To answer your question the NEXT release will be Komodo 6, in general we will always go up by 1 version number unless we provide minor release upgrades for some reason - but not likely. We don't have a release schedule - we release when we think we have something that is more than just trivially better or significantly different in some way that is of value.

Don

[lucasart]

Komodo seems to need SSE4 more than other programs and it's something like 10-20 ELO handicap depending on the time control. At long time controls it's probably less than 10 ELO. I don't know why Komodo depends on this more than other program but obviously we use the popcount and findbit operations more for some reason.

I recommend you just have an SSE 4.2 and an SSE 2 compile. In case the CPU doesn't support SSE 4.2, it will always be assumed at least SSE 2 compliant (I don't think anyone has an older CPU that that these days).

findbit(): Are you talking about bitscan ? (ie. BSFQ in x86-64-assembly). For that you don't need SSE 4.2, and simply using GCC intrinsics with SSE 2 should be fine. That's what I do and both SSE 2 and SSE 4.2 versions of DiscoCheck use hardware bitscan (and reverse bitscan). I suppose GCC will use a couple of BSF in 32-bit SSE 2 compiles, which probably better than using BSF tables (although I've never verified and don't really care about 32-bit computing).

popcount(): for the SSE 2 case, you could use a SWAR popcount like Stockfish. In Stockfish there are two versions: popcount<Max15> and popcount<Full>. In a lot of cases you can use the popcount<Max15> one which is faster.

There are two ways to go about this:
- either (like the Stockfish developpers) you consider that popcount() is a potentially costly instruction, and you build your code in order to be economical of it. For example, Stockfish maintains some piece_cnt[] array, to avoid having to recalcualte it, etc.
- or, you consider that SSE 4.2 is the future, and eventually everyone will have it, and you decide that you invest in the future and you don't care about performance on SSE 2 (like me: I use GCC intrinsic and no SWAR popcount, I trust GCC for the SSE 2 case, and I don't care enough to micro-optimize that).

[Don]

Komodo seems to need SSE4 more than other programs and it's something like 10-20 ELO handicap depending on the time control. At long time controls it's probably less than 10 ELO. I don't know why Komodo depends on this more than other program but obviously we use the popcount and findbit operations more for some reason.

I recommend you just have an SSE 4.2 and an SSE 2 compile. In case the CPU doesn't support SSE 4.2, it will always be assumed at least SSE 2 compliant (I don't think anyone has an older CPU that that these days).

findbit(): Are you talking about bitscan ? (ie. BSFQ in x86-64-assembly). For that you don't need SSE 4.2, and simply using GCC intrinsics with SSE 2 should be fine. That's what I do and both SSE 2 and SSE 4.2 versions of DiscoCheck use hardware bitscan (and reverse bitscan). I suppose GCC will use a couple of BSF in 32-bit SSE 2 compiles, which probably better than using BSF tables (although I've never verified and don't really care about 32-bit computing).

popcount(): for the SSE 2 case, you could use a SWAR popcount like Stockfish. In Stockfish there are two versions: popcount<Max15> and popcount<Full>. In a lot of cases you can use the popcount<Max15> one which is faster.

There are two ways to go about this:
- either (like the Stockfish developpers) you consider that popcount() is a potentially costly instruction, and you build your code in order to be economical of it. For example, Stockfish maintains some piece_cnt[] array, to avoid having to recalcualte it, etc.
- or, you consider that SSE 4.2 is the future, and eventually everyone will have it, and you decide that you invest in the future and you don't care about performance on SSE 2 (like me: I use GCC intrinsic and no SWAR popcount, I trust GCC for the SSE 2 case, and I don't care enough to micro-optimize that).

We take the point of view that chess programming is already difficult enough without also trying to cover every possible combination of hardware and OS so we optimize for the most common non-entry level case. We even considered dropping 32 bit support but this is still going to take a long time to die off I'm afraid.