Komodo 2.03 SSE42 available

[fern]

windows Ikbar, Don...

[Dr.Wael Deeb]

Don:
Do you have an idea about which is the most efective GUi for Komodo running on 32 bits windows?
I have Chessbase -fritz 12- GUI, Arena and Shredder. what do you advice?

fern

Go for the Shredder GUI Fern....
Dr.D

[alpha123]

Don:
Do you have an idea about which is the most efective GUi for Komodo running on 32 bits windows?
I have Chessbase -fritz 12- GUI, Arena and Shredder. what do you advice?

fern

Go for the Shredder GUI Fern....
Dr.D

Definitely.

Peter

[Albert Silver]

Don:
Do you have an idea about which is the most efective GUi for Komodo running on 32 bits windows?
I have Chessbase -fritz 12- GUI, Arena and Shredder. what do you advice?

fern

They all work so it is just a matter of preference.

[rbarreira]

Should the analysis between these versions, even with 'deterministic' turned on, differ?

It would not surprise me if there were differences. Despite optimization obeying the 'as-if' rule, re-ordering of instructions or which branch is taken first could easily affect (for instance) the shape of a tree that is being searched.

Also, Komodo uses floating point for evaluation and so (for instance) an interrupt can shave off the high order bits used for intermediate calculations so that even the same version can produce slightly different results at times.

Excuse the interrupt Dann, but does that sound very strange. An interrupt can cause the result of a floating point calculation to be rounded off or terminated early Would that not invalidate our computers for any serious mathematical, statistical or otherwise scientific application. Or are these interrupts designed into Komodo only? Could the intermediate results not be stored and resumed correctly after the interrupt? How long has this been going on and can we blame Bill Gates

Nondeterministic behaviour with Stockfish -different behaviour compared to a stock compile I mean- was I recall the result of a wrong optimization behaviour in the compilation, but I would not know if Komodo is less deterministic. Is that not problematic for bughunting for instance, I suppose that is why there is a switch?

Eelco

I'm with you, unless someone comes up with a reasonable explanation why interrupts would change the behavior of a program. During any context switch the OS is supposed to store the exact content of all CPU registers, and I've never heard of any rounding taking place for floating point registers during this process...

However, it is true that different compilers may give different results for floating point formats, particularly when unsafe optimizations are enabled (which they sometimes are even without an explicit command line parameter to enable them).

[Dr.Wael Deeb]

windows Ikbar, Don...

[Dann Corbit]

Should the analysis between these versions, even with 'deterministic' turned on, differ?

It would not surprise me if there were differences. Despite optimization obeying the 'as-if' rule, re-ordering of instructions or which branch is taken first could easily affect (for instance) the shape of a tree that is being searched.

Also, Komodo uses floating point for evaluation and so (for instance) an interrupt can shave off the high order bits used for intermediate calculations so that even the same version can produce slightly different results at times.

Excuse the interrupt Dann, but does that sound very strange. An interrupt can cause the result of a floating point calculation to be rounded off or terminated early Would that not invalidate our computers for any serious mathematical, statistical or otherwise scientific application. Or are these interrupts designed into Komodo only? Could the intermediate results not be stored and resumed correctly after the interrupt? How long has this been going on and can we blame Bill Gates

Nondeterministic behaviour with Stockfish -different behaviour compared to a stock compile I mean- was I recall the result of a wrong optimization behaviour in the compilation, but I would not know if Komodo is less deterministic. Is that not problematic for bughunting for instance, I suppose that is why there is a switch?

Eelco

I'm with you, unless someone comes up with a reasonable explanation why interrupts would change the behavior of a program. During any context switch the OS is supposed to store the exact content of all CPU registers, and I've never heard of any rounding taking place for floating point registers during this process...

However, it is true that different compilers may give different results for floating point formats, particularly when unsafe optimizations are enabled (which they sometimes are even without an explicit command line parameter to enable them).

It is possible, for instance, for 4 byte floats to have calculations performed using 8 byte intermediate results. Or for 8 byte floats to have intermediate calculations performed using 10 byte floats. If an IRQ happens, then the results do get saved in registers: 4 byte registers and 8 byte registers, respectively, trimming off a few bits of intermediate precision.

These things can be controlled to some degree by compiler options.

[Gerd Isenberg]

Everyone who considers writing a floating point program should read this paper very carefully (It is the best that I know of):
"What Every Computer Scientist Should Know About. Floating-Point Arithmetic."
by DAVID GOLDBERG

Thanks for the paper hint. And I learned the difference between David Goldberg and David E. Goldberg

[fern]

If you persists, guys, with this sci-fi jargon, I will begin right here a class about differences between pluscuam perfect im greek and the sintaxis of latin and all my writting stuff.

Alea Jacta est
fern

[rbarreira]

Should the analysis between these versions, even with 'deterministic' turned on, differ?

It would not surprise me if there were differences. Despite optimization obeying the 'as-if' rule, re-ordering of instructions or which branch is taken first could easily affect (for instance) the shape of a tree that is being searched.

Also, Komodo uses floating point for evaluation and so (for instance) an interrupt can shave off the high order bits used for intermediate calculations so that even the same version can produce slightly different results at times.

Excuse the interrupt Dann, but does that sound very strange. An interrupt can cause the result of a floating point calculation to be rounded off or terminated early Would that not invalidate our computers for any serious mathematical, statistical or otherwise scientific application. Or are these interrupts designed into Komodo only? Could the intermediate results not be stored and resumed correctly after the interrupt? How long has this been going on and can we blame Bill Gates

Nondeterministic behaviour with Stockfish -different behaviour compared to a stock compile I mean- was I recall the result of a wrong optimization behaviour in the compilation, but I would not know if Komodo is less deterministic. Is that not problematic for bughunting for instance, I suppose that is why there is a switch?

Eelco

I'm with you, unless someone comes up with a reasonable explanation why interrupts would change the behavior of a program. During any context switch the OS is supposed to store the exact content of all CPU registers, and I've never heard of any rounding taking place for floating point registers during this process...

However, it is true that different compilers may give different results for floating point formats, particularly when unsafe optimizations are enabled (which they sometimes are even without an explicit command line parameter to enable them).

It is possible, for instance, for 4 byte floats to have calculations performed using 8 byte intermediate results. Or for 8 byte floats to have intermediate calculations performed using 10 byte floats. If an IRQ happens, then the results do get saved in registers: 4 byte registers and 8 byte registers, respectively, trimming off a few bits of intermediate precision.

These things can be controlled to some degree by compiler options.

Where do you propose that these 10-byte floats with extra precision are stored, if not in registers? How does the CPU calculate on them?

Are you saying that there's a "magic area" on the CPU where extra precision is stored and which doesn't get saved on context switches? I was unable to find anything backing this up and I highly doubt that it's the case.

Everything I've read about context switching indicates that all register content, including floating point, is saved and restored by the OS. On x86 there is a hardware context switch which doesn't save floating point stuff, but it seems that common operating systems don't use it precisely for that reason.