On Friday, 17 June 2016 09:23:18 UTC+7, Keith Randall wrote:
>
> Looks like something is wrong with immediate loading for the 1 << ...
> operation. Could you open a bug with repro instructions? I can look at it
> when 1.8 opens.
>>
>>
@Keith, now that I have found a combination that makes the
On Monday, 20 June 2016 16:35:09 UTC+7, Michael Jones wrote:
>
> Your code (with slightly changed print formatting) on my MacBook Pro:
>
> $ go install
> $ time fasterEratspeed
> Init: 2.885352ms
> Search: 284.849689ms, found 8621475 primes up to 1018429650
> Total: 287.735041ms
>
> real
On Monday, June 20, 2016 at 6:33:29 AM UTC-7, gordo...@gmail.com wrote:
Further to the subject of compiler efficiency, the following is the assembler
code output with array bounds checking turned off (-B) the the inner tight
composite culling loop of FasterEratspeed above (generated with go tool
On Monday, June 20, 2016 at 6:33:29 AM UTC-7, gordo...@gmail.com wrote:
Further to the subject of compiler efficiency, the following is the assembler
code output with array bounds checking turned off (-B) the the inner tight
composite culling loop of FasterEratspeed above (generated with go tool
Edit: Corrected, forgot to change the new count routine to 48 from 8...
We have proven with the straight translation of Daniel Bernstein's C code to
golang that the Sieve of Eratosthenes (SoE) eratspeed runs about the same speed
as the Sieve of Atkin (SoA) primespeed for the same range with
On Saturday, June 18, 2016 at 12:21:21 AM UTC+2, gordo...@gmail.com wrote:
On Friday, June 17, 2016 at 4:48:06 PM UTC+2, gordo...@gmail.com wrote:
> > I am not on a high end Intel CPU now, but when I was I found that with a
> > buffer size adjusted to the L1 cache size (8192 32-bit words or 32
Here is a golang version of Daniel Bernstein's "eratspeed", which is a straight
translation of his C code to golang without any changes other than as necessary
to make it work: https://play.golang.org/p/Sd6qlMQcHF.
It won't run on the golang playground because it takes too long unless one
On Friday, June 17, 2016 at 4:48:06 PM UTC+2, gordo...@gmail.com wrote:
> > I don't see the point to the exercise as far as optimizing golang is
> > concerned.
> It is a general rule that using more registers results in faster code.
Yes, except when they're wasted as in using the extra register
I don't see the point to the exercise as far as optimizing golang is concerned.
Your experiment just shows that Your compiler (GCC?) missed an optimization as
far as reducing backend latency goes.
You may also find that swapping the order of some of the instructions such as
the second and the
I don't see the point of the exercise other than it proves that not putting the
result of an operation back into the same register reduces the latency slightly
for your processor (whatever it is?); I suspect that if you used any other
register such as the unused AX register rather then the R11
> Looks like something is wrong with immediate loading for the 1 << ...
> operation. Could you open a bug with repro instructions? I can look at it
> when 1.8 opens.
I have opened a golang issue #16092 as follows:
https://github.com/golang/go/issues/16092
I may have over-complicated it,
No real surprises with the no bounds checks option (-B), it just eliminated the
array bounds checks with the rest of the code the same (version 1.7beta1):
0x00dd 00221 (main.go:37) MOVQDI, CX
0x00e0 00224 (main.go:37) SHRQ$5, DI
0x00e4 00228
No real surprises with the no bounds checks option (-B), it just eliminated the
array bounds checks with the rest of the code the same (version 1.7beta1):
0x00dd 00221 (main.go:37) MOVQDI, CX
0x00e0 00224 (main.go:37) SHRQ$5, DI
0x00e4 00228
13 matches
Mail list logo
