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"
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.
(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
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
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
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
