FAQ
While doing some dirty basic tests to evaluate the limit of inter-process
communication through TCP, there seems to be sensible performance
regressions since Go 1.0.3.

Here are the results ; I know this is not a solid benchmark but I run the
test many times on Windows XP and a Linux server (64 bits, lower CPU) with
no signifiant differences between runs.

1.0.3

linux : 37s
win32 : 24s

1.1.2

linux : 39s
win32 : 53s (!)

1.2.0

linux : 40s
win32 : 27s

Code link : http://pastebin.com/zgTBCLW3

Is there a reason for the net system calls to be about 10% slower for
version 1.2.0 ?

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Rémy Oudompheng at Sep 29, 2013 at 5:30 pm
    In Go 1.2 the scheduler handles system calls differently. The result
    is that you may need to increase GOMAXPROCS to obtain equivalent
    behaviour.

    Maybe it should be documented in release notes.

    Rémy.


    2013/9/29, dev@nanard.net <dev@nanard.net>:
    While doing some dirty basic tests to evaluate the limit of inter-process
    communication through TCP, there seems to be sensible performance
    regressions since Go 1.0.3.

    Here are the results ; I know this is not a solid benchmark but I run the
    test many times on Windows XP and a Linux server (64 bits, lower CPU) with
    no signifiant differences between runs.

    1.0.3

    linux : 37s
    win32 : 24s

    1.1.2

    linux : 39s
    win32 : 53s (!)

    1.2.0

    linux : 40s
    win32 : 27s

    Code link : http://pastebin.com/zgTBCLW3

    Is there a reason for the net system calls to be about 10% slower for
    version 1.2.0 ?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Sep 29, 2013 at 8:11 pm

    On Sun, Sep 29, 2013 at 10:30 AM, Rémy Oudompheng wrote:
    In Go 1.2 the scheduler handles system calls differently.
    That change was in 1.1.

    The result
    is that you may need to increase GOMAXPROCS to obtain equivalent
    behaviour.

    Maybe it should be documented in release notes.

    Rémy.


    2013/9/29, dev@nanard.net <dev@nanard.net>:
    While doing some dirty basic tests to evaluate the limit of inter-process
    communication through TCP, there seems to be sensible performance
    regressions since Go 1.0.3.

    Here are the results ; I know this is not a solid benchmark but I run the
    test many times on Windows XP and a Linux server (64 bits, lower CPU) with
    no signifiant differences between runs.

    1.0.3

    linux : 37s
    win32 : 24s

    1.1.2

    linux : 39s
    win32 : 53s (!)

    1.2.0

    linux : 40s
    win32 : 27s

    Code link : http://pastebin.com/zgTBCLW3

    Is there a reason for the net system calls to be about 10% slower for
    version 1.2.0 ?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Sep 29, 2013 at 9:16 pm
    Is there some documentation or description of this change?
    On Sunday, September 29, 2013 2:10:55 PM UTC-6, Dmitry Vyukov wrote:

    On Sun, Sep 29, 2013 at 10:30 AM, Rémy Oudompheng
    <remyoud...@gmail.com <javascript:>> wrote:
    In Go 1.2 the scheduler handles system calls differently.
    That change was in 1.1.

    The result
    is that you may need to increase GOMAXPROCS to obtain equivalent
    behaviour.

    Maybe it should be documented in release notes.

    Rémy.


    2013/9/29, d...@nanard.net <javascript:> <d...@nanard.net <javascript:>>:
    While doing some dirty basic tests to evaluate the limit of
    inter-process
    communication through TCP, there seems to be sensible performance
    regressions since Go 1.0.3.

    Here are the results ; I know this is not a solid benchmark but I run
    the
    test many times on Windows XP and a Linux server (64 bits, lower CPU)
    with
    no signifiant differences between runs.

    1.0.3

    linux : 37s
    win32 : 24s

    1.1.2

    linux : 39s
    win32 : 53s (!)

    1.2.0

    linux : 40s
    win32 : 27s

    Code link : http://pastebin.com/zgTBCLW3

    Is there a reason for the net system calls to be about 10% slower for
    version 1.2.0 ?

    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Sep 30, 2013 at 9:50 am
    What kind of documentation do you want? Describing what?


    On Sun, Sep 29, 2013 at 2:16 PM, Kevin Gillette
    wrote:
    Is there some documentation or description of this change?

    On Sunday, September 29, 2013 2:10:55 PM UTC-6, Dmitry Vyukov wrote:

    On Sun, Sep 29, 2013 at 10:30 AM, Rémy Oudompheng
    wrote:
    In Go 1.2 the scheduler handles system calls differently.
    That change was in 1.1.

    The result
    is that you may need to increase GOMAXPROCS to obtain equivalent
    behaviour.

    Maybe it should be documented in release notes.

    Rémy.


    2013/9/29, d...@nanard.net <d...@nanard.net>:
    While doing some dirty basic tests to evaluate the limit of
    inter-process
    communication through TCP, there seems to be sensible performance
    regressions since Go 1.0.3.

    Here are the results ; I know this is not a solid benchmark but I run
    the
    test many times on Windows XP and a Linux server (64 bits, lower CPU)
    with
    no signifiant differences between runs.

    1.0.3

    linux : 37s
    win32 : 24s

    1.1.2

    linux : 39s
    win32 : 53s (!)

    1.2.0

    linux : 40s
    win32 : 27s

    Code link : http://pastebin.com/zgTBCLW3

    Is there a reason for the net system calls to be about 10% slower for
    version 1.2.0 ?

    --
    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...@**googlegroups.com.
    For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>.
    --
    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...@**googlegroups.com.
    For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Sep 30, 2013 at 3:30 pm
    Just a one sentence description about how the scheduler handles syscalls
    differently. e.g. does it now bound threads?
    On Monday, September 30, 2013 3:50:30 AM UTC-6, Dmitry Vyukov wrote:

    What kind of documentation do you want? Describing what?


    On Sun, Sep 29, 2013 at 2:16 PM, Kevin Gillette <extempor...@gmail.com<javascript:>
    wrote:
    Is there some documentation or description of this change?

    On Sunday, September 29, 2013 2:10:55 PM UTC-6, Dmitry Vyukov wrote:

    On Sun, Sep 29, 2013 at 10:30 AM, Rémy Oudompheng
    wrote:
    In Go 1.2 the scheduler handles system calls differently.
    That change was in 1.1.

    The result
    is that you may need to increase GOMAXPROCS to obtain equivalent
    behaviour.

    Maybe it should be documented in release notes.

    Rémy.


    2013/9/29, d...@nanard.net <d...@nanard.net>:
    While doing some dirty basic tests to evaluate the limit of
    inter-process
    communication through TCP, there seems to be sensible performance
    regressions since Go 1.0.3.

    Here are the results ; I know this is not a solid benchmark but I run
    the
    test many times on Windows XP and a Linux server (64 bits, lower CPU)
    with
    no signifiant differences between runs.

    1.0.3

    linux : 37s
    win32 : 24s

    1.1.2

    linux : 39s
    win32 : 53s (!)

    1.2.0

    linux : 40s
    win32 : 27s

    Code link : http://pastebin.com/zgTBCLW3

    Is there a reason for the net system calls to be about 10% slower for
    version 1.2.0 ?

    --
    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...@**googlegroups.com.
    For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>.
    --
    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...@**googlegroups.com.
    For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>.
    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Oct 1, 2013 at 7:15 am
    Before 1.1 the scheduler was pessimistic about syscalls, i.e. it
    assumed that they will block, and so it created/waked a thread to run
    Go code before each syscall.
    Since 1.1 the scheduler is optimistic about syscalls, i.e. it assumes
    that they will not block, so enter/exit syscall becomes almost no-op.
    However, if scheduler later discovers that a syscall takes too long,
    at this point it creates/wakes a thread to run Go code.


    On Mon, Sep 30, 2013 at 7:30 PM, Kevin Gillette
    wrote:
    Just a one sentence description about how the scheduler handles syscalls
    differently. e.g. does it now bound threads?

    On Monday, September 30, 2013 3:50:30 AM UTC-6, Dmitry Vyukov wrote:

    What kind of documentation do you want? Describing what?


    On Sun, Sep 29, 2013 at 2:16 PM, Kevin Gillette <extempor...@gmail.com>
    wrote:
    Is there some documentation or description of this change?

    On Sunday, September 29, 2013 2:10:55 PM UTC-6, Dmitry Vyukov wrote:

    On Sun, Sep 29, 2013 at 10:30 AM, Rémy Oudompheng
    wrote:
    In Go 1.2 the scheduler handles system calls differently.
    That change was in 1.1.

    The result
    is that you may need to increase GOMAXPROCS to obtain equivalent
    behaviour.

    Maybe it should be documented in release notes.

    Rémy.


    2013/9/29, d...@nanard.net <d...@nanard.net>:
    While doing some dirty basic tests to evaluate the limit of
    inter-process
    communication through TCP, there seems to be sensible performance
    regressions since Go 1.0.3.

    Here are the results ; I know this is not a solid benchmark but I run
    the
    test many times on Windows XP and a Linux server (64 bits, lower CPU)
    with
    no signifiant differences between runs.

    1.0.3

    linux : 37s
    win32 : 24s

    1.1.2

    linux : 39s
    win32 : 53s (!)

    1.2.0

    linux : 40s
    win32 : 27s

    Code link : http://pastebin.com/zgTBCLW3

    Is there a reason for the net system calls to be about 10% slower for
    version 1.2.0 ?

    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dev at Oct 1, 2013 at 9:14 am
    If I understand correctly, if no goroutine (explicit or implicit) then no
    scheduler. In other words does what you describe apply to a "linear" code ?
    When not in the context of a goroutine, does a syscall - that takes too
    longs, since 1.1 - implies a thread create/wake ?

    Le mardi 1 octobre 2013 09:15:25 UTC+2, Dmitry Vyukov a écrit :
    Before 1.1 the scheduler was pessimistic about syscalls, i.e. it
    assumed that they will block, and so it created/waked a thread to run
    Go code before each syscall.
    Since 1.1 the scheduler is optimistic about syscalls, i.e. it assumes
    that they will not block, so enter/exit syscall becomes almost no-op.
    *However, if scheduler later discovers that a syscall takes too long,
    at this point it creates/wakes a thread to run Go code.*


    On Mon, Sep 30, 2013 at 7:30 PM, Kevin Gillette
    <extempor...@gmail.com <javascript:>> wrote:
    Just a one sentence description about how the scheduler handles syscalls
    differently. e.g. does it now bound threads?

    On Monday, September 30, 2013 3:50:30 AM UTC-6, Dmitry Vyukov wrote:

    What kind of documentation do you want? Describing what?


    On Sun, Sep 29, 2013 at 2:16 PM, Kevin Gillette <extempor...@gmail.com>
    wrote:
    Is there some documentation or description of this change?

    On Sunday, September 29, 2013 2:10:55 PM UTC-6, Dmitry Vyukov wrote:

    On Sun, Sep 29, 2013 at 10:30 AM, Rémy Oudompheng
    wrote:
    In Go 1.2 the scheduler handles system calls differently.
    That change was in 1.1.

    The result
    is that you may need to increase GOMAXPROCS to obtain equivalent
    behaviour.

    Maybe it should be documented in release notes.

    Rémy.


    2013/9/29, d...@nanard.net <d...@nanard.net>:
    While doing some dirty basic tests to evaluate the limit of
    inter-process
    communication through TCP, there seems to be sensible performance
    regressions since Go 1.0.3.

    Here are the results ; I know this is not a solid benchmark but I
    run
    the
    test many times on Windows XP and a Linux server (64 bits, lower
    CPU)
    with
    no signifiant differences between runs.

    1.0.3

    linux : 37s
    win32 : 24s

    1.1.2

    linux : 39s
    win32 : 53s (!)

    1.2.0

    linux : 40s
    win32 : 27s

    Code link : http://pastebin.com/zgTBCLW3

    Is there a reason for the net system calls to be about 10% slower
    for
    version 1.2.0 ?

    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Oct 1, 2013 at 9:16 am
    I do not understand the question.
    On Tue, Oct 1, 2013 at 2:14 AM, wrote:
    If I understand correctly, if no goroutine (explicit or implicit) then no
    scheduler. In other words does what you describe apply to a "linear" code ?
    When not in the context of a goroutine, does a syscall - that takes too
    longs, since 1.1 - implies a thread create/wake ?

    Le mardi 1 octobre 2013 09:15:25 UTC+2, Dmitry Vyukov a écrit :
    Before 1.1 the scheduler was pessimistic about syscalls, i.e. it
    assumed that they will block, and so it created/waked a thread to run
    Go code before each syscall.
    Since 1.1 the scheduler is optimistic about syscalls, i.e. it assumes
    that they will not block, so enter/exit syscall becomes almost no-op.
    However, if scheduler later discovers that a syscall takes too long,
    at this point it creates/wakes a thread to run Go code.


    On Mon, Sep 30, 2013 at 7:30 PM, Kevin Gillette
    wrote:
    Just a one sentence description about how the scheduler handles syscalls
    differently. e.g. does it now bound threads?

    On Monday, September 30, 2013 3:50:30 AM UTC-6, Dmitry Vyukov wrote:

    What kind of documentation do you want? Describing what?


    On Sun, Sep 29, 2013 at 2:16 PM, Kevin Gillette <extempor...@gmail.com>
    wrote:
    Is there some documentation or description of this change?

    On Sunday, September 29, 2013 2:10:55 PM UTC-6, Dmitry Vyukov wrote:

    On Sun, Sep 29, 2013 at 10:30 AM, Rémy Oudompheng
    wrote:
    In Go 1.2 the scheduler handles system calls differently.
    That change was in 1.1.

    The result
    is that you may need to increase GOMAXPROCS to obtain equivalent
    behaviour.

    Maybe it should be documented in release notes.

    Rémy.


    2013/9/29, d...@nanard.net <d...@nanard.net>:
    While doing some dirty basic tests to evaluate the limit of
    inter-process
    communication through TCP, there seems to be sensible performance
    regressions since Go 1.0.3.

    Here are the results ; I know this is not a solid benchmark but I
    run
    the
    test many times on Windows XP and a Linux server (64 bits, lower
    CPU)
    with
    no signifiant differences between runs.

    1.0.3

    linux : 37s
    win32 : 24s

    1.1.2

    linux : 39s
    win32 : 53s (!)

    1.2.0

    linux : 40s
    win32 : 27s

    Code link : http://pastebin.com/zgTBCLW3

    Is there a reason for the net system calls to be about 10% slower
    for
    version 1.2.0 ?

    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dev at Oct 1, 2013 at 9:47 am
    Excuse me for my poor English.

    func Foo() {
         fmt.Println("Hello")
    }

    func main() {
        Foo()
    }

    Assuming that println does a syscall, will "fmt.Println("Hello")" be
    executed in a new/reused thread (systematically before 1.1, too long since
    1.1), or just if in the context of a goroutine, I mean "go Foo()".

    Le mardi 1 octobre 2013 11:16:11 UTC+2, Dmitry Vyukov a écrit :
    I do not understand the question.
    On Tue, Oct 1, 2013 at 2:14 AM, <d...@nanard.net <javascript:>> wrote:
    If I understand correctly, if no goroutine (explicit or implicit) then no
    scheduler. In other words does what you describe apply to a "linear" code ?
    When not in the context of a goroutine, does a syscall - that takes too
    longs, since 1.1 - implies a thread create/wake ?

    Le mardi 1 octobre 2013 09:15:25 UTC+2, Dmitry Vyukov a écrit :
    Before 1.1 the scheduler was pessimistic about syscalls, i.e. it
    assumed that they will block, and so it created/waked a thread to run
    Go code before each syscall.
    Since 1.1 the scheduler is optimistic about syscalls, i.e. it assumes
    that they will not block, so enter/exit syscall becomes almost no-op.
    However, if scheduler later discovers that a syscall takes too long,
    at this point it creates/wakes a thread to run Go code.


    On Mon, Sep 30, 2013 at 7:30 PM, Kevin Gillette
    wrote:
    Just a one sentence description about how the scheduler handles
    syscalls
    differently. e.g. does it now bound threads?

    On Monday, September 30, 2013 3:50:30 AM UTC-6, Dmitry Vyukov wrote:

    What kind of documentation do you want? Describing what?


    On Sun, Sep 29, 2013 at 2:16 PM, Kevin Gillette <
    extempor...@gmail.com>
    wrote:
    Is there some documentation or description of this change?


    On Sunday, September 29, 2013 2:10:55 PM UTC-6, Dmitry Vyukov
    wrote:
    On Sun, Sep 29, 2013 at 10:30 AM, Rémy Oudompheng
    wrote:
    In Go 1.2 the scheduler handles system calls differently.
    That change was in 1.1.

    The result
    is that you may need to increase GOMAXPROCS to obtain equivalent
    behaviour.

    Maybe it should be documented in release notes.

    Rémy.


    2013/9/29, d...@nanard.net <d...@nanard.net>:
    While doing some dirty basic tests to evaluate the limit of
    inter-process
    communication through TCP, there seems to be sensible
    performance
    regressions since Go 1.0.3.

    Here are the results ; I know this is not a solid benchmark but
    I
    run
    the
    test many times on Windows XP and a Linux server (64 bits,
    lower
    CPU)
    with
    no signifiant differences between runs.

    1.0.3

    linux : 37s
    win32 : 24s

    1.1.2

    linux : 39s
    win32 : 53s (!)

    1.2.0

    linux : 40s
    win32 : 27s

    Code link : http://pastebin.com/zgTBCLW3

    Is there a reason for the net system calls to be about 10%
    slower
    for
    version 1.2.0 ?

    --
    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...@googlegroups.com.
    For more options, visit
    https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Oct 1, 2013 at 11:49 am
    Thank you.
    On Tuesday, October 1, 2013 1:15:25 AM UTC-6, Dmitry Vyukov wrote:

    Before 1.1 the scheduler was pessimistic about syscalls, i.e. it
    assumed that they will block, and so it created/waked a thread to run
    Go code before each syscall.
    Since 1.1 the scheduler is optimistic about syscalls, i.e. it assumes
    that they will not block, so enter/exit syscall becomes almost no-op.
    However, if scheduler later discovers that a syscall takes too long,
    at this point it creates/wakes a thread to run Go code.


    On Mon, Sep 30, 2013 at 7:30 PM, Kevin Gillette
    <extempor...@gmail.com <javascript:>> wrote:
    Just a one sentence description about how the scheduler handles syscalls
    differently. e.g. does it now bound threads?

    On Monday, September 30, 2013 3:50:30 AM UTC-6, Dmitry Vyukov wrote:

    What kind of documentation do you want? Describing what?


    On Sun, Sep 29, 2013 at 2:16 PM, Kevin Gillette <extempor...@gmail.com>
    wrote:
    Is there some documentation or description of this change?

    On Sunday, September 29, 2013 2:10:55 PM UTC-6, Dmitry Vyukov wrote:

    On Sun, Sep 29, 2013 at 10:30 AM, Rémy Oudompheng
    wrote:
    In Go 1.2 the scheduler handles system calls differently.
    That change was in 1.1.

    The result
    is that you may need to increase GOMAXPROCS to obtain equivalent
    behaviour.

    Maybe it should be documented in release notes.

    Rémy.


    2013/9/29, d...@nanard.net <d...@nanard.net>:
    While doing some dirty basic tests to evaluate the limit of
    inter-process
    communication through TCP, there seems to be sensible performance
    regressions since Go 1.0.3.

    Here are the results ; I know this is not a solid benchmark but I
    run
    the
    test many times on Windows XP and a Linux server (64 bits, lower
    CPU)
    with
    no signifiant differences between runs.

    1.0.3

    linux : 37s
    win32 : 24s

    1.1.2

    linux : 39s
    win32 : 53s (!)

    1.2.0

    linux : 40s
    win32 : 27s

    Code link : http://pastebin.com/zgTBCLW3

    Is there a reason for the net system calls to be about 10% slower
    for
    version 1.2.0 ?

    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dev at Sep 29, 2013 at 8:04 pm
    Ok I made a small package with a real benchmark.

    systemcall.go
    http://pastebin.com/tTZViuSd

    systemcall_b_test.go
    http://pastebin.com/E3ZQv3H8

    main.go
    http://pastebin.com/U9HJeFJt


    Tested only under Windows XP :

    ===================================
    1.0.3 -benchtime=10

    GOMAXPROC = 1
    12800 ns/op

    GOMAXPROC = 2
    14000 / 14500 ns/op

    ===================================
    1.2.0 -benchtime=10s

    GOMAXPROC = 1
    15200 ns/op

    GOMAXPROC = 2
    14200 ns/op


    GOMAXPROC=2 improves slightly but now enough...

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Sep 29, 2013 at 8:10 pm

    On Sun, Sep 29, 2013 at 1:04 PM, wrote:
    Ok I made a small package with a real benchmark.

    systemcall.go
    http://pastebin.com/tTZViuSd

    systemcall_b_test.go
    http://pastebin.com/E3ZQv3H8

    main.go
    http://pastebin.com/U9HJeFJt


    Tested only under Windows XP :

    ===================================
    1.0.3 -benchtime=10

    GOMAXPROC = 1
    12800 ns/op

    GOMAXPROC = 2
    14000 / 14500 ns/op

    ===================================
    1.2.0 -benchtime=10s

    GOMAXPROC = 1
    15200 ns/op

    GOMAXPROC = 2
    14200 ns/op


    GOMAXPROC=2 improves slightly but now enough...

    You have only 1 connection, parallelism won't help here.
    If you create a dozen of connections, then GOMAXPROC will help.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dev at Sep 29, 2013 at 8:19 pm
    Exact, I just followed Remy track...

    *"In Go 1.2 the scheduler handles system calls differently. The result
    is that you may need to increase GOMAXPROCS to obtain equivalent
    behaviour. "
    *
    Le dimanche 29 septembre 2013 22:10:29 UTC+2, Dmitry Vyukov a écrit :
    On Sun, Sep 29, 2013 at 1:04 PM, <d...@nanard.net <javascript:>> wrote:
    Ok I made a small package with a real benchmark.

    systemcall.go
    http://pastebin.com/tTZViuSd

    systemcall_b_test.go
    http://pastebin.com/E3ZQv3H8

    main.go
    http://pastebin.com/U9HJeFJt


    Tested only under Windows XP :

    ===================================
    1.0.3 -benchtime=10

    GOMAXPROC = 1
    12800 ns/op

    GOMAXPROC = 2
    14000 / 14500 ns/op

    ===================================
    1.2.0 -benchtime=10s

    GOMAXPROC = 1
    15200 ns/op

    GOMAXPROC = 2
    14200 ns/op


    GOMAXPROC=2 improves slightly but now enough...

    You have only 1 connection, parallelism won't help here.
    If you create a dozen of connections, then GOMAXPROC will help.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dev at Sep 29, 2013 at 9:15 pm
    I made another test with os.Open and os.Read (minimizing real disk access)
    and I can't see any performance regression, i.e. same performance with go
    1.0.3 and go 1.2.0.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brainman at Sep 30, 2013 at 12:27 am
    Not an excuse, but an explanation:

    There were a lot of serious bugs in 1.0.3. These were fixed in 1.1.2. So it
    is unfair to compare current version to 1.0.3. You should compare it to
    1.1.2. And it is about as twice as fast as 1.1.2 as per your experiment.

    Alex

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dev at Sep 30, 2013 at 10:33 am
    I don't need any excuse. I love this language and I try to use it the more
    I can. When I see something that seems to me abnormal, I inform with my
    limited competences. If the experts think it's ok why should I complain ?
    My little experiments did not use garbage collector, nor real compiler
    optimization, in fact my code was just about system call wrappers (as I can
    understand it, may be I'm wrong). Now you say this is a an unfair
    comparison... so be it.

    Le lundi 30 septembre 2013 02:26:56 UTC+2, brainman a écrit :
    Not an excuse, but an explanation:

    There were a lot of serious bugs in 1.0.3. These were fixed in 1.1.2. So
    it is unfair to compare current version to 1.0.3. You should compare it to
    1.1.2. And it is about as twice as fast as 1.1.2 as per your experiment.

    Alex
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brainman at Sep 30, 2013 at 11:58 am

    On Monday, 30 September 2013 20:33:46 UTC+10, d...@nanard.net wrote:
    I don't need any excuse. I love this language and I try to use it the
    more I can. When I see something that seems to me abnormal, I inform with
    my limited competences. ...

    I apologize, I didn't express myself very well. I just tried to explain
    what happened to the best of my abilities. I appreciate you care about Go.
    I do too. I hope no harm done.

    Alex

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dev at Sep 30, 2013 at 1:03 pm
    Don't worry. Your opinion is worth mine.

    To finish with this supposed regression.

    I made a disk test again, and go 1.2 seems faster.

    I extended my benchmark with buffer of different sizes (from 1 byte to
    1024) and results were fluctuating too much (I missed something) so I
    decided to return to a simple test but with sender and receiver in the same
    executable (a goroutine for the sender) and a small buffer (16 bytes, I
    hope same default value for SetNoDelay) . With GOMAXPROCS=1 Go 1.0.3 is far
    faster, but with GOMAXPROCS=2, Go 1.2 is slightly faster. I think we can
    close this thread, as there too many uncertainties.

    Code here :
    http://pastebin.com/iJznPtQT

    Le lundi 30 septembre 2013 13:58:01 UTC+2, brainman a écrit :
    On Monday, 30 September 2013 20:33:46 UTC+10, d...@nanard.net wrote:
    I don't need any excuse. I love this language and I try to use it the
    more I can. When I see something that seems to me abnormal, I inform with
    my limited competences. ...

    I apologize, I didn't express myself very well. I just tried to explain
    what happened to the best of my abilities. I appreciate you care about Go.
    I do too. I hope no harm done.

    Alex
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 29, '13 at 3:50p
activeOct 1, '13 at 11:49a
posts19
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase