I believe rsc once quipped "If it doesn't have to be correct, I can make [this
code] very fast".
I don't think you can make performance comparisons between two pieces of code
if one is incorrect.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group
Excellent, now it's all consistent. Thank you, sir.
https://play.golang.org/p/cKANdyqXen
Still a bit confused as to why the code elimination in the previous
examples yielded code with such differing performance, but at I'm glad that
locality was not the culprit.
Thanks everyone for your input.
Those arguments must live beyond the scope of the enclosing function.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
F
(I have now recreated it on my Mac, under 1.7rc5, the runtime differences
are still there.) I thought the compiler was removing these as you suggest,
but then StartEnd and EndStart had wildly different running times, despite
using the very same values. So I added dummy assignments to double chec
Tu cast pola s ktorou pracujes mas v L1/ L2 cache. V momente ked
pristupujes k inej casti pola ktora je niekolko megabajtov vzdialena tak
procesor musi natiahnut tie udaje z ram do cache. Neviem presne cisla ale
trva to zhruba tych 300 strojovych cyklov . Vypadok L2 neviem kolko trva,
je to v m
Downgrading to 1.6.3, I'm also getting consistent benchmark results. I'll
try 1.7 on my Mac at home later today, to see if it's a 1.7 thing or a
Windows thing or...?
On Wednesday, 3 August 2016 14:55:20 UTC+1, C Banning wrote:
>
> PS - that's with Go v1.6.
>
> On Wednesday, August 3, 2016 at 7:4
PS - that's with Go v1.6.
On Wednesday, August 3, 2016 at 7:49:49 AM UTC-6, C Banning wrote:
>
> On MacBook Pro, 2.6 GHz Intel Core i7, 8 GB 1600 MHz memory, running OS X
> 10.11.6, your benchmarks look pretty consistent:
>
>
> BenchmarkStart-4 20 1.45 ns/op
>
> BenchmarkEnd-
On MacBook Pro, 2.6 GHz Intel Core i7, 8 GB 1600 MHz memory, running OS X
10.11.6, your benchmarks look pretty consistent:
BenchmarkStart-4 20 1.45 ns/op
BenchmarkEnd-420 1.47 ns/op
BenchmarkHereThere-4 20 1.46 ns/op
BenchmarkSta
On MacBook Pro, 2.6 GHz Intel Core i7, 8 GB 1600 MHz memory, you benchmarks
look pretty consistent:
BenchmarkStart-4 20 1.45 ns/op
BenchmarkEnd-420 1.47 ns/op
BenchmarkHereThere-4 20 1.46 ns/op
BenchmarkStartEnd-4 20
With times under one nanosecond I'm wondering what you're actually
measuring. Aggressive optimization could make this an "empty" loop.
Synthetic benchmarks like this can be tricky to interpret.
On Wednesday, August 3, 2016 at 7:56:32 AM UTC-4, Ondrej wrote:
>
> I wanted to see if there was a
10 matches
Mail list logo