FAQ
Reviewers: golang-dev_googlegroups.com,

Message:
Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go


Description:
runtime: use vDSO clock_gettime for time.now & runtime.nanotime on
Linux/amd64
Performance improvement aside, time.Now() now gets real nanosecond
precision
on supported system.

Benchmark done on Core i7-2600 @ 3.40GHz with kernel 3.5.2-gentoo.
original vDSO gettimeofday:
BenchmarkNow 100000000 27.4 ns/op
new vDSO gettimeofday fallback:
BenchmarkNow 100000000 27.6 ns/op
new vDSO clock_gettime:
BenchmarkNow 100000000 24.4 ns/op

Please review this at http://codereview.appspot.com/6814103/

Affected files:
M src/pkg/runtime/sys_linux_amd64.s
M src/pkg/runtime/vdso_linux_amd64.c


Index: src/pkg/runtime/sys_linux_amd64.s
===================================================================
--- a/src/pkg/runtime/sys_linux_amd64.s
+++ b/src/pkg/runtime/sys_linux_amd64.s
@@ -102,31 +102,37 @@

// func now() (sec int64, nsec int32)
TEXT time·now(SB), 7, $32
+ MOVQ runtime·__vdso_clock_gettime_sym(SB), AX
+ CMPQ AX, $0
+ JEQ fallback_gtod
+ MOVL $0, DI // CLOCK_REALTIME
+ LEAQ 8(SP), SI
+ CALL AX
+ MOVQ 8(SP), AX // sec
+ MOVQ 16(SP), DX // nsec
+ MOVQ AX, sec+0(FP)
+ MOVL DX, nsec+8(FP)
+ RET
+fallback_gtod:
LEAQ 8(SP), DI
MOVQ $0, SI
MOVQ runtime·__vdso_gettimeofday_sym(SB), AX
CALL AX
MOVQ 8(SP), AX // sec
MOVL 16(SP), DX // usec
-
- // sec is in AX, usec in DX
+ IMULQ $1000, DX
MOVQ AX, sec+0(FP)
- IMULQ $1000, DX
MOVL DX, nsec+8(FP)
RET

TEXT runtime·nanotime(SB), 7, $32
- LEAQ 8(SP), DI
- MOVQ $0, SI
- MOVQ $0xffffffffff600000, AX
- CALL AX
- MOVQ 8(SP), AX // sec
- MOVL 16(SP), DX // usec
+ CALL time·now(SB)
+ MOVQ 0(SP), AX // sec
+ MOVL 8(SP), DX // nsec

// sec is in AX, usec in DX
// return nsec in AX
IMULQ $1000000000, AX
- IMULQ $1000, DX
ADDQ DX, AX
RET

Index: src/pkg/runtime/vdso_linux_amd64.c
===================================================================
--- a/src/pkg/runtime/vdso_linux_amd64.c
+++ b/src/pkg/runtime/vdso_linux_amd64.c
@@ -161,11 +161,13 @@
// initialize with vsyscall fallbacks
void* runtime·__vdso_time_sym = (void*)0xffffffffff600400ULL;
void* runtime·__vdso_gettimeofday_sym = (void*)0xffffffffff600000ULL;
+void* runtime·__vdso_clock_gettime_sym = (void*)0;

-#define SYM_KEYS_COUNT 2
+#define SYM_KEYS_COUNT 3
static symbol_key sym_keys[] = {
{ (byte*)"__vdso_time", &runtime·__vdso_time_sym },
{ (byte*)"__vdso_gettimeofday", &runtime·__vdso_gettimeofday_sym },
+ { (byte*)"__vdso_clock_gettime", &runtime·__vdso_clock_gettime_sym },
};

static void vdso_init_from_sysinfo_ehdr(struct vdso_info *vdso_info,
Elf64_Ehdr* hdr) {

Search Discussions

  • Minux at Nov 8, 2012 at 10:59 am
    this CL lets runtime.nanotime call time.now.

    if necessary, i can duplicate time.now code for runtime.nanotime to speed
    the
    latter up a little (as did before).
  • Minux Ma at Nov 8, 2012 at 1:23 pm
    FYI, on linux/386, using clock_gettime actually slows time.now() down.

    110 ns/op vs. 118 ns/op.

    This huge performance difference is due to the lack of vDSO
    clock_gettime and gettimeofday on linux/386.

    https://codereview.appspot.com/6814103/
  • Brad Fitzpatrick at Nov 8, 2012 at 4:23 pm
    My personal opinion is that a 8 ns loss on a platform where people don't
    run servers is far outweighed by any speed-up or increase in functionality
    (nanosecond resolution) elsewhere.
    On Thu, Nov 8, 2012 at 7:23 AM, wrote:

    FYI, on linux/386, using clock_gettime actually slows time.now() down.

    110 ns/op vs. 118 ns/op.

    This huge performance difference is due to the lack of vDSO
    clock_gettime and gettimeofday on linux/386.

    https://codereview.appspot.**com/6814103/<https://codereview.appspot.com/6814103/>
  • Iant at Nov 8, 2012 at 4:43 pm
  • Minux at Nov 8, 2012 at 4:50 pm
    what do you think of using clock_gettime on all
    unix systems where ns resolution is available?

    should i add 386 code in this cl or in a subsequent cl?
  • Ian Lance Taylor at Nov 8, 2012 at 5:14 pm

    On Thu, Nov 8, 2012 at 8:50 AM, minux wrote:
    what do you think of using clock_gettime on all
    unix systems where ns resolution is available?
    Sounds like a good idea to me, unless it is slower.
    should i add 386 code in this cl or in a subsequent cl?
    Subsequent CL, I think. This CL is pretty amd64 specific, and the 386
    code will be quite different.

    Ian
  • Minux Ma at Nov 9, 2012 at 6:19 am
    *** Submitted as
    http://code.google.com/p/go/source/detail?r=42c8d3aadc40 ***

    runtime: use vDSO clock_gettime for time.now & runtime.nanotime on
    Linux/amd64
    Performance improvement aside, time.Now() now gets real nanosecond
    resolution
    on supported systems.

    Benchmark done on Core i7-2600 @ 3.40GHz with kernel 3.5.2-gentoo.
    original vDSO gettimeofday:
    BenchmarkNow 100000000 27.4 ns/op
    new vDSO gettimeofday fallback:
    BenchmarkNow 100000000 27.6 ns/op
    new vDSO clock_gettime:
    BenchmarkNow 100000000 24.4 ns/op

    R=golang-dev, bradfitz, iant, iant
    CC=golang-dev
    http://codereview.appspot.com/6814103


    http://codereview.appspot.com/6814103/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedNov 8, '12 at 10:47a
activeNov 9, '12 at 6:19a
posts8
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase