GNU/Linux S5R3 App 4.31 available for Beta test
8 Feb 2008 11:04:25 UTC
Topic 13648
(moderation:
A new Linux App is available from our Beta Test page.
This App looks a little faster than the previous 4.24 due to some hacking with the sin/cos routine, and it is a new "separate graphics" App (featuring the "extended information" mentioned in the "screensver competition" thread).
It's probably not the fastest we can do w/o SSE, but in contrast tothe quick-fix 4.24 it's an actual release candidate.
Please test and report!
BM
BM
GNU/Linux S5R3 App 4.31 available for Beta test
)
There is some tuning on single instructions in the sin/cos approximation code which should give a few % overall compared to the 4.24. IThis won't bring it up to the speed of the 4.27, though.
BM
BM
RE: So it took only 16-17%
)
Actually the speedup is more than I expected. However I recently learned that the fiddling eith the sin/cos code led to the compiler handling other parts of the code differently. The speedup you see is largely "delayed" from the the 4.20 -> 4.24 code changes (where there was a speedup announced but not actually observerd). It's not bound to the sin/cos stuff itself, and thus can't be ported to the SSE version - it's already included there.
BM
BM
RE: Do you have any idea
)
Both compilers (gcc and MSVC) produce inefficient code in the "hot-loop" because they think they have too few FPU registers left for efficient code. On gcc you can get away lucky and it produces efficient code, denpending on how you fiddle with the sin/cos routine, but the MSC compiler seems to do it bad almost always, and the code is worse than that of the gcc.
I asked Akos to write an efficient implementation of the hot-loop in x87 assembler to be independent of the compiler; he agreed to do this, but I haven't received any code yet.
BM
BM
RE: RE: I asked Akos to
)
No problem. I actually wasn't sure, but a simple "hot-loop" will probably do for a start. We are still experimenting with how get the compilers to do the float->int conversion in the sin/cos routine efficiently, but if we find we need assembler here, too, we could probably add it later anyway.
BM
BM
I published the 4.31. Let's
)
I published the 4.31. Let's see how things go. I definitely need to fix the signal 11 problem "officially".
BM
BM
RE: RE: Hi! This
)
The FPE (at least the ones I've seen here) would almost always lead to a NaN in a certain variable and this to an error with exit status 99 a few instructions later (when there is a sanity check for array bounds). So these errors are taken from the "99" bunch of computing errors in order to get closer to the point where the error actually occurs, that's all.
There is at least one other reason for FPEs: a flaw in the operating system (or even in the compiler it was built with). Actually it should protect one process context against whatever is happening in other contexts, but apparently this doesn't alway work correctly. At least on Windows I read reports where a hardware driver (usually printer) could mess up the FPU stack and flags so badly that they weren't properly restored when switching back to a user process, generating an FPE there. I'm not sure that all possible Linux kernels (including self-built) have sufficient protection against bad drivers and other stuff running in kernel mode. I'm not even sure they all properly save all registers - I've seen the CPU type / register detection of the Linux fail to detect the right CPU (and thus available set of registers) at least in two cases.
You seem to have quite a number of machine running, can you point me to the machine or even better the result where the error happened with the 4.35?
BM
BM
The 4.31 App has become part
)
The 4.31 App has become part of the new 4.38 beta App package.
BM
BM