FAQ
Hello,

I recently saw this post on Hacker
News: http://fabiensanglard.net/rayTracing_back_of_business_card/index.php
I found the implementation fascinating and wanted to code the same up in
Go: https://github.com/kid0m4n/gorays
The C++ version is here: https://gist.github.com/kid0m4n/6680629

Both of them produce the same (or similar looking) PPK
image: http://i.imgur.com/yFicPrE.png

I have tried to make the Go version as optimal as possible (single
goroutine)

Initial numbers (on my Late 2011 MBP 15, 2.2 Ghz Quad Core (2675QM), 16 GB
RAM, OX 10.9, Go 1.1.2):

C++ version: 11.803 s
Go version: 28.883 s

The go version can be installed using a: *go get github.com/kid0m4n/gorays*
*
*
Pull requests are welcome.

Regards,
Karan

--
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

  • Karan Misra at Sep 24, 2013 at 5:36 am
    Just so that it is clear: The intention is to get Go as fast as possible. I
    know this is not Go's intended application right now, but why not?
    On Tuesday, September 24, 2013 11:04:09 AM UTC+5:30, Karan Misra wrote:

    Hello,

    I recently saw this post on Hacker News:
    http://fabiensanglard.net/rayTracing_back_of_business_card/index.php
    I found the implementation fascinating and wanted to code the same up in
    Go: https://github.com/kid0m4n/gorays
    The C++ version is here: https://gist.github.com/kid0m4n/6680629

    Both of them produce the same (or similar looking) PPK image:
    http://i.imgur.com/yFicPrE.png

    I have tried to make the Go version as optimal as possible (single
    goroutine)

    Initial numbers (on my Late 2011 MBP 15, 2.2 Ghz Quad Core (2675QM), 16
    GB RAM, OX 10.9, Go 1.1.2):

    C++ version: 11.803 s
    Go version: 28.883 s

    The go version can be installed using a: *go get github.com/kid0m4n/gorays
    *
    *
    *
    Pull requests are welcome.

    Regards,
    Karan
    --
    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.
  • Karan Misra at Sep 24, 2013 at 7:04 am
    I just tried with go 1.2rc1 and the time has improved to 25.644s

    So that is definitely good news

    Things I have tried in terms of optimizations:

        1. Pointers instead of values for operating on vectors (no improvement)
        2. float32 instead of float64 (no improvement)
    On Tuesday, September 24, 2013 11:06:48 AM UTC+5:30, Karan Misra wrote:

    Just so that it is clear: The intention is to get Go as fast as possible.
    I know this is not Go's intended application right now, but why not?
    On Tuesday, September 24, 2013 11:04:09 AM UTC+5:30, Karan Misra wrote:

    Hello,

    I recently saw this post on Hacker News:
    http://fabiensanglard.net/rayTracing_back_of_business_card/index.php
    I found the implementation fascinating and wanted to code the same up in
    Go: https://github.com/kid0m4n/gorays
    The C++ version is here: https://gist.github.com/kid0m4n/6680629

    Both of them produce the same (or similar looking) PPK image:
    http://i.imgur.com/yFicPrE.png

    I have tried to make the Go version as optimal as possible (single
    goroutine)

    Initial numbers (on my Late 2011 MBP 15, 2.2 Ghz Quad Core (2675QM), 16
    GB RAM, OX 10.9, Go 1.1.2):

    C++ version: 11.803 s
    Go version: 28.883 s

    The go version can be installed using a: *go get
    github.com/kid0m4n/gorays*
    *
    *
    Pull requests are welcome.

    Regards,
    Karan
    --
    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.
  • Nigel Tao at Sep 24, 2013 at 7:45 am

    On Tue, Sep 24, 2013 at 5:04 PM, Karan Misra wrote:
    Things I have tried in terms of optimizations:

    Pointers instead of values for operating on vectors (no improvement)
    float32 instead of float64 (no improvement)
    Try pulling the os.Stdout.Write call out of your inner loop.

    --
    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.
  • Robert Melton at Sep 24, 2013 at 8:26 am

    On Tue, Sep 24, 2013 at 3:45 AM, Nigel Tao wrote:
    On Tue, Sep 24, 2013 at 5:04 PM, Karan Misra wrote:
    Things I have tried in terms of optimizations:

    Pointers instead of values for operating on vectors (no improvement)
    float32 instead of float64 (no improvement)
    Try pulling the os.Stdout.Write call out of your inner loop.
    Just swapped it with a buffer, nice little 11% bump on my box.

    --
    Robert Melton

    --
    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.
  • Sebastien Binet at Sep 24, 2013 at 8:54 am

    On Tue, Sep 24, 2013 at 10:26 AM, Robert Melton wrote:
    On Tue, Sep 24, 2013 at 3:45 AM, Nigel Tao wrote:
    On Tue, Sep 24, 2013 at 5:04 PM, Karan Misra wrote:
    Things I have tried in terms of optimizations:

    Pointers instead of values for operating on vectors (no improvement)
    float32 instead of float64 (no improvement)
    Try pulling the os.Stdout.Write call out of your inner loop.
    Just swapped it with a buffer, nice little 11% bump on my box.
    also, w/o looking at any cpuprofile data (so pinch of salt needed),
    you might want to remove the use of (the thread-safe) rand.Float64
    here:
    https://github.com/kid0m4n/gorays/blob/master/main.go#L60
    and use a local rand instead.

    see:
    http://golang.org/src/pkg/math/rand/rand.go?s=4272:4294#L136
    http://golang.org/src/pkg/math/rand/rand.go?s=4272:4294#L91
    http://golang.org/src/pkg/math/rand/rand.go?s=4272:4294#L179

    -s

    --
    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.
  • Karan Misra at Sep 24, 2013 at 10:16 am
    You might be right on the money. I did examine the cpuprofile data and had
    seen the rand.Float64() highlighted.

    Another issue though, even during the 28 second run, only 40 or so samples
    were collected. I thought it was one sample every 10 ms?
    On Tuesday, September 24, 2013 2:24:01 PM UTC+5:30, Sebastien Binet wrote:
    On Tue, Sep 24, 2013 at 10:26 AM, Robert Melton wrote:
    On Tue, Sep 24, 2013 at 3:45 AM, Nigel Tao wrote:
    On Tue, Sep 24, 2013 at 5:04 PM, Karan Misra wrote:
    Things I have tried in terms of optimizations:

    Pointers instead of values for operating on vectors (no improvement)
    float32 instead of float64 (no improvement)
    Try pulling the os.Stdout.Write call out of your inner loop.
    Just swapped it with a buffer, nice little 11% bump on my box.
    also, w/o looking at any cpuprofile data (so pinch of salt needed),
    you might want to remove the use of (the thread-safe) rand.Float64
    here:
    https://github.com/kid0m4n/gorays/blob/master/main.go#L60
    and use a local rand instead.

    see:
    http://golang.org/src/pkg/math/rand/rand.go?s=4272:4294#L136
    http://golang.org/src/pkg/math/rand/rand.go?s=4272:4294#L91
    http://golang.org/src/pkg/math/rand/rand.go?s=4272:4294#L179

    -s
    --
    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.
  • Dan Kortschak at Sep 24, 2013 at 1:30 pm
    Try replacing your calls to r.Float64() with this:

    var seed = ^uint32(0)

    func Rand() float64 {
      seed += seed
      seed ^= 1
      if int32(seed) < 0 {
       seed ^= 0x88888eef
      }
      return float64(seed%95)/float64(95)
    }

    Pilfered with modification from the regexp tests and proposed by Rob. It
    knocks off another 5% for me.

    --
    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.
  • Karan Misra at Sep 24, 2013 at 2:00 pm
    Yep, works. But didn't get the 5% improvement though. Will try on a Linux
    machine and report back

    Go1.2rc1
    Changeset: https://github.com/kid0m4n/gorays/commit/9066519c24a092b7f672b71327f5c825f84a77a4
    Before: 12.747s
    After: 12.644s
    Improvement: 0.103s (0.8%)
    Origin version in OP: 28.883s
    Improvement since OP: *16.239s (56.22%)*
    Original C version: 11.803s
    Slowness: 0.841s
    Slowness to C++ version: *7.12%* (Go version is so close now)
    On Tuesday, September 24, 2013 7:00:17 PM UTC+5:30, kortschak wrote:

    Try replacing your calls to r.Float64() with this:

    var seed = ^uint32(0)

    func Rand() float64 {
    seed += seed
    seed ^= 1
    if int32(seed) < 0 {
    seed ^= 0x88888eef
    }
    return float64(seed%95)/float64(95)
    }

    Pilfered with modification from the regexp tests and proposed by Rob. It
    knocks off another 5% for me.
    --
    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.
  • Karan Misra at Sep 24, 2013 at 2:04 pm
    0.3s improvement on Linux
    On Tuesday, September 24, 2013 7:30:01 PM UTC+5:30, Karan Misra wrote:

    Yep, works. But didn't get the 5% improvement though. Will try on a Linux
    machine and report back

    Go1.2rc1
    Changeset:
    https://github.com/kid0m4n/gorays/commit/9066519c24a092b7f672b71327f5c825f84a77a4
    Before: 12.747s
    After: 12.644s
    Improvement: 0.103s (0.8%)
    Origin version in OP: 28.883s
    Improvement since OP: *16.239s (56.22%)*
    Original C version: 11.803s
    Slowness: 0.841s
    Slowness to C++ version: *7.12%* (Go version is so close now)
    On Tuesday, September 24, 2013 7:00:17 PM UTC+5:30, kortschak wrote:

    Try replacing your calls to r.Float64() with this:

    var seed = ^uint32(0)

    func Rand() float64 {
    seed += seed
    seed ^= 1
    if int32(seed) < 0 {
    seed ^= 0x88888eef
    }
    return float64(seed%95)/float64(95)
    }

    Pilfered with modification from the regexp tests and proposed by Rob. It
    knocks off another 5% for me.
    --
    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.
  • Karan Misra at Sep 24, 2013 at 2:17 pm
    go1.2rc1 pprof:

    Total: 10580 samples
    5420 51.2% 51.2% 5435 51.4% main.tracer
    2672 25.3% 76.5% 10563 99.8% main.main
    659 6.2% 82.7% 1347 12.7% math.Pow
    444 4.2% 86.9% 683 6.5%
    github.com/kid0m4n/gorays/vector.Vector.Normalize
    419 4.0% 90.9% 7287 68.9% main.sampler
    248 2.3% 93.2% 248 2.3% math.Sqrt
    200 1.9% 95.1% 308 2.9% math.ldexp
    165 1.6% 96.7% 165 1.6% math.modf
    142 1.3% 98.0% 174 1.6% math.normalize
    134 1.3% 99.3% 200 1.9% math.frexp
    32 0.3% 99.6% 32 0.3% math.Abs
    13 0.1% 99.7% 13 0.1% math.Ceil
    7 0.1% 99.8% 7 0.1% math.Frexp
    7 0.1% 99.8% 7 0.1% math.Modf
    6 0.1% 99.9% 6 0.1% runtime.newstack

    pprof web output: http://i.imgur.com/BCopize.png
    On Tuesday, September 24, 2013 7:33:58 PM UTC+5:30, Karan Misra wrote:

    0.3s improvement on Linux
    On Tuesday, September 24, 2013 7:30:01 PM UTC+5:30, Karan Misra wrote:

    Yep, works. But didn't get the 5% improvement though. Will try on a Linux
    machine and report back

    Go1.2rc1
    Changeset:
    https://github.com/kid0m4n/gorays/commit/9066519c24a092b7f672b71327f5c825f84a77a4
    Before: 12.747s
    After: 12.644s
    Improvement: 0.103s (0.8%)
    Origin version in OP: 28.883s
    Improvement since OP: *16.239s (56.22%)*
    Original C version: 11.803s
    Slowness: 0.841s
    Slowness to C++ version: *7.12%* (Go version is so close now)
    On Tuesday, September 24, 2013 7:00:17 PM UTC+5:30, kortschak wrote:

    Try replacing your calls to r.Float64() with this:

    var seed = ^uint32(0)

    func Rand() float64 {
    seed += seed
    seed ^= 1
    if int32(seed) < 0 {
    seed ^= 0x88888eef
    }
    return float64(seed%95)/float64(95)
    }

    Pilfered with modification from the regexp tests and proposed by Rob. It
    knocks off another 5% for me.
    --
    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.
  • Donovan Hide at Sep 24, 2013 at 2:28 pm
    Hi,

    try the --lines flag on pprof to get a bit more detail on main()
    bottlenecks. Also look at the linux perf tool:

    https://perf.wiki.kernel.org/index.php/Main_Page

    Cheers,
    Donovan.

    On 24 September 2013 15:17, Karan Misra wrote:

    go1.2rc1 pprof:

    Total: 10580 samples
    5420 51.2% 51.2% 5435 51.4% main.tracer
    2672 25.3% 76.5% 10563 99.8% main.main
    659 6.2% 82.7% 1347 12.7% math.Pow
    444 4.2% 86.9% 683 6.5%
    github.com/kid0m4n/gorays/vector.Vector.Normalize
    419 4.0% 90.9% 7287 68.9% main.sampler
    248 2.3% 93.2% 248 2.3% math.Sqrt
    200 1.9% 95.1% 308 2.9% math.ldexp
    165 1.6% 96.7% 165 1.6% math.modf
    142 1.3% 98.0% 174 1.6% math.normalize
    134 1.3% 99.3% 200 1.9% math.frexp
    32 0.3% 99.6% 32 0.3% math.Abs
    13 0.1% 99.7% 13 0.1% math.Ceil
    7 0.1% 99.8% 7 0.1% math.Frexp
    7 0.1% 99.8% 7 0.1% math.Modf
    6 0.1% 99.9% 6 0.1% runtime.newstack

    pprof web output: http://i.imgur.com/BCopize.png
    On Tuesday, September 24, 2013 7:33:58 PM UTC+5:30, Karan Misra wrote:

    0.3s improvement on Linux
    On Tuesday, September 24, 2013 7:30:01 PM UTC+5:30, Karan Misra wrote:

    Yep, works. But didn't get the 5% improvement though. Will try on a
    Linux machine and report back

    Go1.2rc1
    Changeset: https://github.com/**kid0m4n/gorays/commit/**
    9066519c24a092b7f672b71327f5c8**25f84a77a4<https://github.com/kid0m4n/gorays/commit/9066519c24a092b7f672b71327f5c825f84a77a4>
    Before: 12.747s
    After: 12.644s
    Improvement: 0.103s (0.8%)
    Origin version in OP: 28.883s
    Improvement since OP: *16.239s (56.22%)*
    Original C version: 11.803s
    Slowness: 0.841s
    Slowness to C++ version: *7.12%* (Go version is so close now)
    On Tuesday, September 24, 2013 7:00:17 PM UTC+5:30, kortschak wrote:

    Try replacing your calls to r.Float64() with this:

    var seed = ^uint32(0)

    func Rand() float64 {
    seed += seed
    seed ^= 1
    if int32(seed) < 0 {
    seed ^= 0x88888eef
    }
    return float64(seed%95)/float64(95)
    }

    Pilfered with modification from the regexp tests and proposed by Rob.
    It
    knocks off another 5% for me.

    --
    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.
  • Karan Misra at Sep 24, 2013 at 4:53 pm
    Thanks for the tip :)
    On Tuesday, September 24, 2013 7:58:45 PM UTC+5:30, Donovan wrote:

    Hi,

    try the --lines flag on pprof to get a bit more detail on main()
    bottlenecks. Also look at the linux perf tool:

    https://perf.wiki.kernel.org/index.php/Main_Page

    Cheers,
    Donovan.


    On 24 September 2013 15:17, Karan Misra <kid...@gmail.com <javascript:>>wrote:
    go1.2rc1 pprof:

    Total: 10580 samples
    5420 51.2% 51.2% 5435 51.4% main.tracer
    2672 25.3% 76.5% 10563 99.8% main.main
    659 6.2% 82.7% 1347 12.7% math.Pow
    444 4.2% 86.9% 683 6.5%
    github.com/kid0m4n/gorays/vector.Vector.Normalize
    419 4.0% 90.9% 7287 68.9% main.sampler
    248 2.3% 93.2% 248 2.3% math.Sqrt
    200 1.9% 95.1% 308 2.9% math.ldexp
    165 1.6% 96.7% 165 1.6% math.modf
    142 1.3% 98.0% 174 1.6% math.normalize
    134 1.3% 99.3% 200 1.9% math.frexp
    32 0.3% 99.6% 32 0.3% math.Abs
    13 0.1% 99.7% 13 0.1% math.Ceil
    7 0.1% 99.8% 7 0.1% math.Frexp
    7 0.1% 99.8% 7 0.1% math.Modf
    6 0.1% 99.9% 6 0.1% runtime.newstack

    pprof web output: http://i.imgur.com/BCopize.png
    On Tuesday, September 24, 2013 7:33:58 PM UTC+5:30, Karan Misra wrote:

    0.3s improvement on Linux
    On Tuesday, September 24, 2013 7:30:01 PM UTC+5:30, Karan Misra wrote:

    Yep, works. But didn't get the 5% improvement though. Will try on a
    Linux machine and report back

    Go1.2rc1
    Changeset: https://github.com/**kid0m4n/gorays/commit/**
    9066519c24a092b7f672b71327f5c8**25f84a77a4<https://github.com/kid0m4n/gorays/commit/9066519c24a092b7f672b71327f5c825f84a77a4>
    Before: 12.747s
    After: 12.644s
    Improvement: 0.103s (0.8%)
    Origin version in OP: 28.883s
    Improvement since OP: *16.239s (56.22%)*
    Original C version: 11.803s
    Slowness: 0.841s
    Slowness to C++ version: *7.12%* (Go version is so close now)
    On Tuesday, September 24, 2013 7:00:17 PM UTC+5:30, kortschak wrote:

    Try replacing your calls to r.Float64() with this:

    var seed = ^uint32(0)

    func Rand() float64 {
    seed += seed
    seed ^= 1
    if int32(seed) < 0 {
    seed ^= 0x88888eef
    }
    return float64(seed%95)/float64(95)
    }

    Pilfered with modification from the regexp tests and proposed by Rob.
    It
    knocks off another 5% for me.

    --
    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.
  • Karan Misra at Sep 24, 2013 at 10:25 pm
    Now that we are so close to C level performance, I tried to see how easy it
    would be to expand the solution to effectively use all cores on the host
    machine.

    Needless to say, I was not disappointed.

    Go1.2rc1
    Changeset: https://github.com/kid0m4n/gorays/commit/7420ef3f94be2dd0d1887d98cdbec67a14a07f9f
    Before: 12.644s
    After: 2.360
    Improvement: *10.284s* (*81.33%*)
    Origin version in OP: 28.883s
    Improvement since OP: *26.523s (91.83%)*
    Original C version: 11.803s
    Improvement: *9.443s*
    Improvement to C++ version: *80%* (Hurray!)

    Must say, Go is proving to be very parallel in this particular usecase. Any
    comments on the parallel version?

    https://github.com/kid0m4n/gorays/blob/7420ef3f94be2dd0d1887d98cdbec67a14a07f9f/main.go
    On Tuesday, September 24, 2013 10:23:48 PM UTC+5:30, Karan Misra wrote:

    Thanks for the tip :)
    On Tuesday, September 24, 2013 7:58:45 PM UTC+5:30, Donovan wrote:

    Hi,

    try the --lines flag on pprof to get a bit more detail on main()
    bottlenecks. Also look at the linux perf tool:

    https://perf.wiki.kernel.org/index.php/Main_Page

    Cheers,
    Donovan.

    On 24 September 2013 15:17, Karan Misra wrote:

    go1.2rc1 pprof:

    Total: 10580 samples
    5420 51.2% 51.2% 5435 51.4% main.tracer
    2672 25.3% 76.5% 10563 99.8% main.main
    659 6.2% 82.7% 1347 12.7% math.Pow
    444 4.2% 86.9% 683 6.5%
    github.com/kid0m4n/gorays/vector.Vector.Normalize
    419 4.0% 90.9% 7287 68.9% main.sampler
    248 2.3% 93.2% 248 2.3% math.Sqrt
    200 1.9% 95.1% 308 2.9% math.ldexp
    165 1.6% 96.7% 165 1.6% math.modf
    142 1.3% 98.0% 174 1.6% math.normalize
    134 1.3% 99.3% 200 1.9% math.frexp
    32 0.3% 99.6% 32 0.3% math.Abs
    13 0.1% 99.7% 13 0.1% math.Ceil
    7 0.1% 99.8% 7 0.1% math.Frexp
    7 0.1% 99.8% 7 0.1% math.Modf
    6 0.1% 99.9% 6 0.1% runtime.newstack

    pprof web output: http://i.imgur.com/BCopize.png
    On Tuesday, September 24, 2013 7:33:58 PM UTC+5:30, Karan Misra wrote:

    0.3s improvement on Linux
    On Tuesday, September 24, 2013 7:30:01 PM UTC+5:30, Karan Misra wrote:

    Yep, works. But didn't get the 5% improvement though. Will try on a
    Linux machine and report back

    Go1.2rc1
    Changeset: https://github.com/**kid0m4n/gorays/commit/**
    9066519c24a092b7f672b71327f5c8**25f84a77a4<https://github.com/kid0m4n/gorays/commit/9066519c24a092b7f672b71327f5c825f84a77a4>
    Before: 12.747s
    After: 12.644s
    Improvement: 0.103s (0.8%)
    Origin version in OP: 28.883s
    Improvement since OP: *16.239s (56.22%)*
    Original C version: 11.803s
    Slowness: 0.841s
    Slowness to C++ version: *7.12%* (Go version is so close now)
    On Tuesday, September 24, 2013 7:00:17 PM UTC+5:30, kortschak wrote:

    Try replacing your calls to r.Float64() with this:

    var seed = ^uint32(0)

    func Rand() float64 {
    seed += seed
    seed ^= 1
    if int32(seed) < 0 {
    seed ^= 0x88888eef
    }
    return float64(seed%95)/float64(95)
    }

    Pilfered with modification from the regexp tests and proposed by Rob.
    It
    knocks off another 5% for me.

    --
    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.
  • Dan Kortschak at Sep 24, 2013 at 10:57 pm
    Did you try chunking it into n chunks and starting a goroutine for each of the n chunks as needed? This would get rid of your per-row chan communication.
    On 25/09/2013, at 7:55 AM, "Karan Misra" wrote:

    Must say, Go is proving to be very parallel in this particular usecase. Any comments on the parallel version?
    --
    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.
  • Karan Misra at Sep 25, 2013 at 3:24 am
    :)

    I did: https://github.com/kid0m4n/gorays/blob/parallel/main.go
    I tried 3 approaches
    infact: https://github.com/kid0m4n/gorays/commits/parallel

    But this turned out to be 2 seconds faster on a i7 2600 for a 2000x2000
    image. So merged it into master.
    On Wednesday, September 25, 2013 4:27:20 AM UTC+5:30, kortschak wrote:

    Did you try chunking it into n chunks and starting a goroutine for each of
    the n chunks as needed? This would get rid of your per-row chan
    communication.

    On 25/09/2013, at 7:55 AM, "Karan Misra" <kid...@gmail.com <javascript:>>
    wrote:
    Must say, Go is proving to be very parallel in this particular usecase.
    Any comments on the parallel version?
    --
    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.
  • Nigel Tao at Sep 24, 2013 at 11:01 pm

    On Wed, Sep 25, 2013 at 8:25 AM, Karan Misra wrote:
    Now that we are so close to C level performance,
    IIUC, your spheres spell out "Go" but the C code spells out "aek".
    Does changing your "art" strings affect your running time?

    --
    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.
  • Wes Freeman at Sep 24, 2013 at 11:04 pm
    I wondered this too.
    On Tue, Sep 24, 2013 at 7:00 PM, Nigel Tao wrote:
    On Wed, Sep 25, 2013 at 8:25 AM, Karan Misra wrote:
    Now that we are so close to C level performance,
    IIUC, your spheres spell out "Go" but the C code spells out "aek".
    Does changing your "art" strings affect your running time?

    --
    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 25, 2013 at 12:37 am
    I imagine it would have to. The description of the algorithm is such that
    if a ray does not encounter a sphere, it falls back to a very quick
    checkerboard color or sky gradient determination. The scene with the fewest
    spheres would therefore generate more quickly than the one with the most.
    On Tuesday, September 24, 2013 5:00:59 PM UTC-6, Nigel Tao wrote:
    On Wed, Sep 25, 2013 at 8:25 AM, Karan Misra wrote:
    Now that we are so close to C level performance,
    IIUC, your spheres spell out "Go" but the C code spells out "aek".
    Does changing your "art" strings affect your running time?
    --
    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.
  • Karan Misra at Sep 25, 2013 at 3:29 am
    The modified C/C++ I used to get the 11.803s runtime has been modified to
    generate the same exact pattern as the Go
    one: https://gist.github.com/kid0m4n/6680629
    (while the original one used in source does generate aek)

    But, since after this
    commit: https://github.com/kid0m4n/gorays/commit/249f229ba8c769c38d7dc018acfdf29cc86d6e43
    it is no longer an apples to apples comparison.
    On Wednesday, September 25, 2013 6:07:30 AM UTC+5:30, Kevin Gillette wrote:

    I imagine it would have to. The description of the algorithm is such that
    if a ray does not encounter a sphere, it falls back to a very quick
    checkerboard color or sky gradient determination. The scene with the fewest
    spheres would therefore generate more quickly than the one with the most.
    On Tuesday, September 24, 2013 5:00:59 PM UTC-6, Nigel Tao wrote:
    On Wed, Sep 25, 2013 at 8:25 AM, Karan Misra wrote:
    Now that we are so close to C level performance,
    IIUC, your spheres spell out "Go" but the C code spells out "aek".
    Does changing your "art" strings affect your running time?
    --
    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.
  • Roger peppe at Sep 25, 2013 at 8:50 am

    On 24 September 2013 23:25, Karan Misra wrote:
    Must say, Go is proving to be very parallel in this particular usecase. Any
    comments on the parallel version?
    I'd structure it slightly differently. There's no need to add to
    the WaitGroup in every row.

    Something like this, perhaps:
    http://play.golang.org/p/3bq226CdPI

    I see another ~6% speedup from that.

    --
    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.
  • Karan Misra at Sep 26, 2013 at 1:10 am
    Rog,

    This definitely looks to be a better way of doing
    it: https://github.com/kid0m4n/gorays/commit/ddfe825f0902877c02467a4f65f46c4044bc7939

    Thanks for the tip.

    -k
    On Wednesday, September 25, 2013 2:20:42 PM UTC+5:30, rog wrote:

    On 24 September 2013 23:25, Karan Misra <kid...@gmail.com <javascript:>>
    wrote:
    Must say, Go is proving to be very parallel in this particular usecase. Any
    comments on the parallel version?
    I'd structure it slightly differently. There's no need to add to
    the WaitGroup in every row.

    Something like this, perhaps:
    http://play.golang.org/p/3bq226CdPI

    I see another ~6% speedup from that.
    --
    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.
  • Michael Jones at Sep 26, 2013 at 2:18 am
    Karan, making this change:

    if st == missUpward {
    //return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(math.Pow(1-dir.Z, 4))
      p := 1-dir.Z
    p = p*p
    p = p*p
    return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(p)
      }

    saves 5.4% on runtime. Generally, using a general tool (Pow, which works
    for all real exponents) when all you really want is x**4, is very expensive.

    Michael
    (in Kuala Lumpur)

    On Thu, Sep 26, 2013 at 9:09 AM, Karan Misra wrote:

    Rog,

    This definitely looks to be a better way of doing it:
    https://github.com/kid0m4n/gorays/commit/ddfe825f0902877c02467a4f65f46c4044bc7939

    Thanks for the tip.

    -k
    On Wednesday, September 25, 2013 2:20:42 PM UTC+5:30, rog wrote:
    On 24 September 2013 23:25, Karan Misra wrote:
    Must say, Go is proving to be very parallel in this particular usecase. Any
    comments on the parallel version?
    I'd structure it slightly differently. There's no need to add to
    the WaitGroup in every row.

    Something like this, perhaps:
    http://play.golang.org/p/**3bq226CdPI<http://play.golang.org/p/3bq226CdPI>

    I see another ~6% speedup from that.
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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.
  • Karan Misra at Sep 26, 2013 at 2:29 am
    Thanks Michael. I love how these numbers are adding up :)

    Changeset: https://github.com/kid0m4n/gorays/commit/527e08317c9307316e2a7a8e9379cf40778eeaa1

    I am summarizing the various changes in a blog post :)
    On Thursday, September 26, 2013 7:47:43 AM UTC+5:30, Michael Jones wrote:

    Karan, making this change:

    if st == missUpward {
    //return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(math.Pow(1-dir.Z, 4))
    p := 1-dir.Z
    p = p*p
    p = p*p
    return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(p)
    }

    saves 5.4% on runtime. Generally, using a general tool (Pow, which works
    for all real exponents) when all you really want is x**4, is very expensive.

    Michael
    (in Kuala Lumpur)


    On Thu, Sep 26, 2013 at 9:09 AM, Karan Misra <kid...@gmail.com<javascript:>
    wrote:
    Rog,

    This definitely looks to be a better way of doing it:
    https://github.com/kid0m4n/gorays/commit/ddfe825f0902877c02467a4f65f46c4044bc7939

    Thanks for the tip.

    -k
    On Wednesday, September 25, 2013 2:20:42 PM UTC+5:30, rog wrote:
    On 24 September 2013 23:25, Karan Misra wrote:
    Must say, Go is proving to be very parallel in this particular
    usecase. Any
    comments on the parallel version?
    I'd structure it slightly differently. There's no need to add to
    the WaitGroup in every row.

    Something like this, perhaps:
    http://play.golang.org/p/**3bq226CdPI<http://play.golang.org/p/3bq226CdPI>

    I see another ~6% speedup from that.
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>
    +1 650-335-5765
    --
    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.
  • Michael Jones at Sep 26, 2013 at 2:31 am
    There is also something strange about width and height. They do not scale
    in such a way that the same image is rendered at higher resolution.
    Instead, an MUCH easier image is rendered because the bulk of the image is
    away from the reflective spheres.

    See the two attached images. "Small" was rendered in the default 512x512
    size. "Large" was at 2000x2000 then reduced in Photoshop to 512x512. Note
    the increase in the number of "single ray intersection" cases.

    On Thu, Sep 26, 2013 at 10:17 AM, Michael Jones wrote:

    Karan, making this change:

    if st == missUpward {
    //return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(math.Pow(1-dir.Z, 4))
    p := 1-dir.Z
    p = p*p
    p = p*p
    return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(p)
    }

    saves 5.4% on runtime. Generally, using a general tool (Pow, which works
    for all real exponents) when all you really want is x**4, is very expensive.

    Michael
    (in Kuala Lumpur)

    On Thu, Sep 26, 2013 at 9:09 AM, Karan Misra wrote:

    Rog,

    This definitely looks to be a better way of doing it:
    https://github.com/kid0m4n/gorays/commit/ddfe825f0902877c02467a4f65f46c4044bc7939

    Thanks for the tip.

    -k
    On Wednesday, September 25, 2013 2:20:42 PM UTC+5:30, rog wrote:
    On 24 September 2013 23:25, Karan Misra wrote:
    Must say, Go is proving to be very parallel in this particular
    usecase. Any
    comments on the parallel version?
    I'd structure it slightly differently. There's no need to add to
    the WaitGroup in every row.

    Something like this, perhaps:
    http://play.golang.org/p/**3bq226CdPI<http://play.golang.org/p/3bq226CdPI>

    I see another ~6% speedup from that.
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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.
  • Karan Misra at Sep 26, 2013 at 2:36 am
    Yep. I have noticed that before. I am working towards a fix which will also
    scale the objects along with the image size.
    On Thursday, September 26, 2013 8:00:50 AM UTC+5:30, Michael Jones wrote:

    There is also something strange about width and height. They do not scale
    in such a way that the same image is rendered at higher resolution.
    Instead, an MUCH easier image is rendered because the bulk of the image is
    away from the reflective spheres.

    See the two attached images. "Small" was rendered in the default 512x512
    size. "Large" was at 2000x2000 then reduced in Photoshop to 512x512. Note
    the increase in the number of "single ray intersection" cases.


    On Thu, Sep 26, 2013 at 10:17 AM, Michael Jones <m...@google.com<javascript:>
    wrote:
    Karan, making this change:

    if st == missUpward {
    //return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(math.Pow(1-dir.Z, 4))
    p := 1-dir.Z
    p = p*p
    p = p*p
    return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(p)
    }

    saves 5.4% on runtime. Generally, using a general tool (Pow, which works
    for all real exponents) when all you really want is x**4, is very expensive.

    Michael
    (in Kuala Lumpur)


    On Thu, Sep 26, 2013 at 9:09 AM, Karan Misra <kid...@gmail.com<javascript:>
    wrote:
    Rog,

    This definitely looks to be a better way of doing it:
    https://github.com/kid0m4n/gorays/commit/ddfe825f0902877c02467a4f65f46c4044bc7939

    Thanks for the tip.

    -k
    On Wednesday, September 25, 2013 2:20:42 PM UTC+5:30, rog wrote:
    On 24 September 2013 23:25, Karan Misra wrote:
    Must say, Go is proving to be very parallel in this particular
    usecase. Any
    comments on the parallel version?
    I'd structure it slightly differently. There's no need to add to
    the WaitGroup in every row.

    Something like this, perhaps:
    http://play.golang.org/p/**3bq226CdPI<http://play.golang.org/p/3bq226CdPI>

    I see another ~6% speedup from that.
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>
    +1 650-335-5765


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>
    +1 650-335-5765
    --
    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.
  • Karan Misra at Sep 26, 2013 at 2:36 am
    Or a pull request :P :)
    On Thursday, September 26, 2013 8:05:54 AM UTC+5:30, Karan Misra wrote:

    Yep. I have noticed that before. I am working towards a fix which will
    also scale the objects along with the image size.
    On Thursday, September 26, 2013 8:00:50 AM UTC+5:30, Michael Jones wrote:

    There is also something strange about width and height. They do not scale
    in such a way that the same image is rendered at higher resolution.
    Instead, an MUCH easier image is rendered because the bulk of the image is
    away from the reflective spheres.

    See the two attached images. "Small" was rendered in the default 512x512
    size. "Large" was at 2000x2000 then reduced in Photoshop to 512x512. Note
    the increase in the number of "single ray intersection" cases.

    On Thu, Sep 26, 2013 at 10:17 AM, Michael Jones wrote:

    Karan, making this change:

    if st == missUpward {
    //return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(math.Pow(1-dir.Z, 4))
    p := 1-dir.Z
    p = p*p
    p = p*p
    return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(p)
    }

    saves 5.4% on runtime. Generally, using a general tool (Pow, which works
    for all real exponents) when all you really want is x**4, is very expensive.

    Michael
    (in Kuala Lumpur)

    On Thu, Sep 26, 2013 at 9:09 AM, Karan Misra wrote:

    Rog,

    This definitely looks to be a better way of doing it:
    https://github.com/kid0m4n/gorays/commit/ddfe825f0902877c02467a4f65f46c4044bc7939

    Thanks for the tip.

    -k
    On Wednesday, September 25, 2013 2:20:42 PM UTC+5:30, rog wrote:
    On 24 September 2013 23:25, Karan Misra wrote:
    Must say, Go is proving to be very parallel in this particular
    usecase. Any
    comments on the parallel version?
    I'd structure it slightly differently. There's no need to add to
    the WaitGroup in every row.

    Something like this, perhaps:
    http://play.golang.org/p/**3bq226CdPI<http://play.golang.org/p/3bq226CdPI>

    I see another ~6% speedup from that.
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765
    --
    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.
  • Michael Jones at Sep 26, 2013 at 9:55 am
    Further, you compute an expensive Pow for "p" that you may not need because
    of an intervening return. Moving it below the if/return saves 5.98% of
    overall runtime:

    if st == missDownward {

    h = h.Scale(0.2)
    fc := vector.Vector{X: 3, Y: 3, Z: 3}
      if int(math.Ceil(h.X)+math.Ceil(h.Y))&1 == 1 {
    fc = vector.Vector{X: 3, Y: 1, Z: 1}
    }
      return fc.Scale(b*0.2 + 0.1)
    }

    //moving here after possible return saves 5.98% of execution time
             p := math.Pow(l.DotProduct(r.Scale(sf)), 99)
             return vector.Vector{X: p, Y: p, Z: p}.Add(sampler(h, r).Scale(0.5))

    ...but that's not all. That Pow() of x**99 is expensive. Doing it
    explicitly saves an additional 2.33% of execution time.

    //computing x**99 explicitly saves a further 2.33% of execution time
    //p := math.Pow(l.DotProduct(r.Scale(sf)), 99)
      p := l.DotProduct(r.Scale(sf))
    p33 := p * p // p**2
    p33 = p33 * p33 // p**4
      p33 = p33 * p33 // p**8
    p33 = p33 * p33 // p**16
    p33 = p33 * p33 // p**32
      p33 = p33 * p // p**33
    p = p33 * p33 * p33 // p**99
    return vector.Vector{X: p, Y: p, Z: p}.Add(sampler(h, r).Scale(0.5))

    Michael

    P.S. Note the way I calculate p**99 saves multiplies compared to
    p64*p32*p2*p. This is why I'd rather see exponentiation in a language. It
    allows the compiler to optimize the multiply chains.

    On Thu, Sep 26, 2013 at 10:36 AM, Karan Misra wrote:

    Or a pull request :P :)

    On Thursday, September 26, 2013 8:05:54 AM UTC+5:30, Karan Misra wrote:

    Yep. I have noticed that before. I am working towards a fix which will
    also scale the objects along with the image size.
    On Thursday, September 26, 2013 8:00:50 AM UTC+5:30, Michael Jones wrote:

    There is also something strange about width and height. They do not
    scale in such a way that the same image is rendered at higher resolution.
    Instead, an MUCH easier image is rendered because the bulk of the image is
    away from the reflective spheres.

    See the two attached images. "Small" was rendered in the default 512x512
    size. "Large" was at 2000x2000 then reduced in Photoshop to 512x512. Note
    the increase in the number of "single ray intersection" cases.

    On Thu, Sep 26, 2013 at 10:17 AM, Michael Jones wrote:

    Karan, making this change:

    if st == missUpward {
    //return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(math.Pow(1-dir.Z, 4))
    p := 1-dir.Z
    p = p*p
    p = p*p
    return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(p)
    }

    saves 5.4% on runtime. Generally, using a general tool (Pow, which
    works for all real exponents) when all you really want is x**4, is very
    expensive.

    Michael
    (in Kuala Lumpur)

    On Thu, Sep 26, 2013 at 9:09 AM, Karan Misra wrote:

    Rog,

    This definitely looks to be a better way of doing it:
    https://github.com/**kid0m4n/gorays/commit/**
    ddfe825f0902877c02467a4f65f46c**4044bc7939<https://github.com/kid0m4n/gorays/commit/ddfe825f0902877c02467a4f65f46c4044bc7939>

    Thanks for the tip.

    -k
    On Wednesday, September 25, 2013 2:20:42 PM UTC+5:30, rog wrote:
    On 24 September 2013 23:25, Karan Misra wrote:
    Must say, Go is proving to be very parallel in this particular
    usecase. Any
    comments on the parallel version?
    I'd structure it slightly differently. There's no need to add to
    the WaitGroup in every row.

    Something like this, perhaps:
    http://play.golang.org/p/**3bq22**6CdPI<http://play.golang.org/p/3bq226CdPI>

    I see another ~6% speedup from that.
    --
    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>
    .


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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.
  • Karan Misra at Oct 2, 2013 at 10:35 am
    Michael,

    Thanks to your tip and one further optimization, a further 12.01 %
    improvement was made which made the Go version faster than the C++ version
    in the single-threaded test.

    I have summarized this and all other optimizations in this blog
    post: https://kidoman.com/programming/go-getter.html

    <https://kidoman.com/images/go-vs-cpp-after-optimizations.png>


    Hope it is useful for everyone.
    On Thursday, September 26, 2013 3:24:25 PM UTC+5:30, Michael Jones wrote:

    Further, you compute an expensive Pow for "p" that you may not need
    because of an intervening return. Moving it below the if/return saves 5.98%
    of overall runtime:

    if st == missDownward {

    h = h.Scale(0.2)
    fc := vector.Vector{X: 3, Y: 3, Z: 3}
    if int(math.Ceil(h.X)+math.Ceil(h.Y))&1 == 1 {
    fc = vector.Vector{X: 3, Y: 1, Z: 1}
    }
    return fc.Scale(b*0.2 + 0.1)
    }

    //moving here after possible return saves 5.98% of execution time
    p := math.Pow(l.DotProduct(r.Scale(sf)), 99)
    return vector.Vector{X: p, Y: p, Z: p}.Add(sampler(h,
    r).Scale(0.5))

    ...but that's not all. That Pow() of x**99 is expensive. Doing it
    explicitly saves an additional 2.33% of execution time.

    //computing x**99 explicitly saves a further 2.33% of execution time
    //p := math.Pow(l.DotProduct(r.Scale(sf)), 99)
    p := l.DotProduct(r.Scale(sf))
    p33 := p * p // p**2
    p33 = p33 * p33 // p**4
    p33 = p33 * p33 // p**8
    p33 = p33 * p33 // p**16
    p33 = p33 * p33 // p**32
    p33 = p33 * p // p**33
    p = p33 * p33 * p33 // p**99
    return vector.Vector{X: p, Y: p, Z: p}.Add(sampler(h, r).Scale(0.5))

    Michael

    P.S. Note the way I calculate p**99 saves multiplies compared to
    p64*p32*p2*p. This is why I'd rather see exponentiation in a language. It
    allows the compiler to optimize the multiply chains.


    On Thu, Sep 26, 2013 at 10:36 AM, Karan Misra <kid...@gmail.com<javascript:>
    wrote:
    Or a pull request :P :)

    On Thursday, September 26, 2013 8:05:54 AM UTC+5:30, Karan Misra wrote:

    Yep. I have noticed that before. I am working towards a fix which will
    also scale the objects along with the image size.
    On Thursday, September 26, 2013 8:00:50 AM UTC+5:30, Michael Jones wrote:

    There is also something strange about width and height. They do not
    scale in such a way that the same image is rendered at higher resolution.
    Instead, an MUCH easier image is rendered because the bulk of the image is
    away from the reflective spheres.

    See the two attached images. "Small" was rendered in the default
    512x512 size. "Large" was at 2000x2000 then reduced in Photoshop to
    512x512. Note the increase in the number of "single ray intersection" cases.

    On Thu, Sep 26, 2013 at 10:17 AM, Michael Jones wrote:

    Karan, making this change:

    if st == missUpward {
    //return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(math.Pow(1-dir.Z,
    4))
    p := 1-dir.Z
    p = p*p
    p = p*p
    return vector.Vector{X: 0.7, Y: 0.6, Z: 1}.Scale(p)
    }

    saves 5.4% on runtime. Generally, using a general tool (Pow, which
    works for all real exponents) when all you really want is x**4, is very
    expensive.

    Michael
    (in Kuala Lumpur)

    On Thu, Sep 26, 2013 at 9:09 AM, Karan Misra wrote:

    Rog,

    This definitely looks to be a better way of doing it:
    https://github.com/**kid0m4n/gorays/commit/**
    ddfe825f0902877c02467a4f65f46c**4044bc7939<https://github.com/kid0m4n/gorays/commit/ddfe825f0902877c02467a4f65f46c4044bc7939>

    Thanks for the tip.

    -k
    On Wednesday, September 25, 2013 2:20:42 PM UTC+5:30, rog wrote:
    On 24 September 2013 23:25, Karan Misra wrote:
    Must say, Go is proving to be very parallel in this particular
    usecase. Any
    comments on the parallel version?
    I'd structure it slightly differently. There's no need to add to
    the WaitGroup in every row.

    Something like this, perhaps:
    http://play.golang.org/p/**3bq22**6CdPI<http://play.golang.org/p/3bq226CdPI>

    I see another ~6% speedup from that.
    --
    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>
    .


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>
    +1 650-335-5765
    --
    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.
  • Jan Mercl at Oct 2, 2013 at 10:39 am
    On Wed, Oct 2, 2013 at 12:35 PM, Karan Misra wrote:

    Very god job!

    -j

    --
    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.
  • Karan Misra at Oct 2, 2013 at 11:39 am
    Merci :)
    On Wednesday, October 2, 2013 4:09:28 PM UTC+5:30, Jan Mercl wrote:

    On Wed, Oct 2, 2013 at 12:35 PM, Karan Misra wrote:

    Very god job!

    -j
    --
    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.
  • Jfcgauss at Oct 2, 2013 at 1:40 pm
    Hi Karan,

    Tiny patch for making it flexible for any size text array to render:

    --- main.go Wed Oct 2 15:49:36 2013
    +++ main.go Wed Oct 2 15:59:44 2013
    @@ -31,11 +31,13 @@
      }

      func makeObjects() []object {
    - objects := make([]object, 0, len(art)*len(art[0]))
    - for k := 18; k >= 0; k-- {
    - for j := 8; j >= 0; j-- {
    - if string(art[j][18-k]) != " " {
    - objects = append(objects, object{k: k, j: 8 - j})
    + nr := len(art)
    + nc := len(art[0])
    + objects := make([]object, 0, nr*nc)
    + for k := nc - 1; k >= 0; k-- {
    + for j := nr - 1; j >= 0; j-- {
    + if art[j][nc-1-k] != ' ' {
    + objects = append(objects, object{k: k, j: nr - 1 - j})
       }
       }
       }

    --
    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.
  • Karan Misra at Oct 2, 2013 at 6:13 pm
    Cool :) Patched in...
    On Wednesday, October 2, 2013 7:09:57 PM UTC+5:30, jfcg...@gmail.com wrote:

    Hi Karan,

    Tiny patch for making it flexible for any size text array to render:

    --- main.go Wed Oct 2 15:49:36 2013
    +++ main.go Wed Oct 2 15:59:44 2013
    @@ -31,11 +31,13 @@
    }

    func makeObjects() []object {
    - objects := make([]object, 0, len(art)*len(art[0]))
    - for k := 18; k >= 0; k-- {
    - for j := 8; j >= 0; j-- {
    - if string(art[j][18-k]) != " " {
    - objects = append(objects, object{k: k, j: 8 - j})
    + nr := len(art)
    + nc := len(art[0])
    + objects := make([]object, 0, nr*nc)
    + for k := nc - 1; k >= 0; k-- {
    + for j := nr - 1; j >= 0; j-- {
    + if art[j][nc-1-k] != ' ' {
    + objects = append(objects, object{k: k, j: nr - 1 - j})
    }
    }
    }
    --
    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.
  • Karan Misra at Oct 3, 2013 at 12:42 am
    Guys,

    So I took the plunge and ported over the "optimizations" to C++, and reran
    the benchmarks:

    https://kidoman.com/programming/go-getter-part-2.html

    The optimized C++
    version: https://github.com/kid0m4n/gorays/blob/master/ref/rays.cpp
    The and optimization
    diffs: https://github.com/kid0m4n/gorays/compare/bbb8395aa999883a595267fd0230087b1ddf646c...940c91f601ef840e6d75ddf272ab6cd3eb8d5531

    At this point, they are essentially running the same algorithms as well.
    When rendering a 2048x2048 image, C++ wins by a margin of around ~22 seconds
    Is it worth looking at why there is such a gap? (knowns / unknowns) Worth
    investing time optimizing Go to bridge the gap / lower it?

    I know this is not Go's target market (I guess), but why shouldn't it be
    the fastest m*f* language out there?

    -k
    (go fanatic)
    On Wednesday, October 2, 2013 11:43:37 PM UTC+5:30, Karan Misra wrote:

    Cool :) Patched in...

    On Wednesday, October 2, 2013 7:09:57 PM UTC+5:30, jfcg...@gmail.comwrote:
    Hi Karan,

    Tiny patch for making it flexible for any size text array to render:

    --- main.go Wed Oct 2 15:49:36 2013
    +++ main.go Wed Oct 2 15:59:44 2013
    @@ -31,11 +31,13 @@
    }

    func makeObjects() []object {
    - objects := make([]object, 0, len(art)*len(art[0]))
    - for k := 18; k >= 0; k-- {
    - for j := 8; j >= 0; j-- {
    - if string(art[j][18-k]) != " " {
    - objects = append(objects, object{k: k, j: 8 - j})
    + nr := len(art)
    + nc := len(art[0])
    + objects := make([]object, 0, nr*nc)
    + for k := nc - 1; k >= 0; k-- {
    + for j := nr - 1; j >= 0; j-- {
    + if art[j][nc-1-k] != ' ' {
    + objects = append(objects, object{k: k, j: nr - 1 - j})
    }
    }
    }
    --
    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.
  • Andrey mirtchovski at Oct 3, 2013 at 12:56 am
    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on today's
    internet. you saw what happened in the reddit thread: negativity and
    outright dismissal without even considering that the point was not to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the direct
    comparison with C++, yet most people still latched only on that).
    I know this is not Go's target market (I guess), but why shouldn't it be the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most" programming
    language in many categories. simplicity, clarity, and generality are
    the key to Go, and I'd be reluctant to give them up for a minute
    improvement in a contrived microbenchmark. besides, I think your
    program is impressively fast as it is.

    --
    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.
  • Michael Jones at Oct 3, 2013 at 1:06 am
    C compilers are very good. At some point you are simply benchmarking
    compiler (as opposed to language) maturity. One of the first replies to the
    original post was "Have you tried this with GCCGO?" You might want to do
    that...

    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski wrote:

    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on today's
    internet. you saw what happened in the reddit thread: negativity and
    outright dismissal without even considering that the point was not to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the direct
    comparison with C++, yet most people still latched only on that).
    I know this is not Go's target market (I guess), but why shouldn't it be the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most" programming
    language in many categories. simplicity, clarity, and generality are
    the key to Go, and I'd be reluctant to give them up for a minute
    improvement in a contrived microbenchmark. besides, I think your
    program is impressively fast as it is.

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


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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.
  • Karan Misra at Oct 3, 2013 at 1:43 am
    True. But then, these tests can also act as a litmus test for the maturity
    level of the Go compiler.

    For example, I was looking at what methods which were being inlined in the
    vector package. Definitely saw some weird signals there.

    Also, had totally forgotten about gccgo. Will definitely give it a spin.

    Sent from my iPhone

    On 03-Oct-2013, at 6:36, Michael Jones wrote:

    C compilers are very good. At some point you are simply benchmarking
    compiler (as opposed to language) maturity. One of the first replies to the
    original post was "Have you tried this with GCCGO?" You might want to do
    that...

    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski wrote:

    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on today's
    internet. you saw what happened in the reddit thread: negativity and
    outright dismissal without even considering that the point was not to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the direct
    comparison with C++, yet most people still latched only on that).
    I know this is not Go's target market (I guess), but why shouldn't it be the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most" programming
    language in many categories. simplicity, clarity, and generality are
    the key to Go, and I'd be reluctant to give them up for a minute
    improvement in a contrived microbenchmark. besides, I think your
    program is impressively fast as it is.

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


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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.
  • Gustavo Niemeyer at Oct 3, 2013 at 5:05 pm
    Not to mention the original code was optimized to be printed on a
    business card. A ray tracer on a business card. Hard to beat.
    On Wed, Oct 2, 2013 at 10:05 PM, Michael Jones wrote:
    C compilers are very good. At some point you are simply benchmarking
    compiler (as opposed to language) maturity. One of the first replies to the
    original post was "Have you tried this with GCCGO?" You might want to do
    that...

    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski wrote:

    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on today's
    internet. you saw what happened in the reddit thread: negativity and
    outright dismissal without even considering that the point was not to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the direct
    comparison with C++, yet most people still latched only on that).
    I know this is not Go's target market (I guess), but why shouldn't it be
    the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most" programming
    language in many categories. simplicity, clarity, and generality are
    the key to Go, and I'd be reluctant to give them up for a minute
    improvement in a contrived microbenchmark. besides, I think your
    program is impressively fast as it is.

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



    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

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


    --

    gustavo @ http://niemeyer.net

    --
    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 4, 2013 at 2:31 am
    Agreed. I've no doubt that the original could have been much more highly
    optimized, but for example, manual loop unrolling would be contrary to the
    goal of getting the most functional value per unit of code volume; as soon
    as we expanded the code beyond (un-gofmt'd, minified) business-card size,
    the comparison to the original is moot.

    How efficient and functional can we get a Go raytracer, at an
    equivalent-to-original text display size, when restricted to the size of a
    business card?
    On Thursday, October 3, 2013 11:05:17 AM UTC-6, Gustavo Niemeyer wrote:

    Not to mention the original code was optimized to be printed on a
    business card. A ray tracer on a business card. Hard to beat.
    On Wed, Oct 2, 2013 at 10:05 PM, Michael Jones wrote:
    C compilers are very good. At some point you are simply benchmarking
    compiler (as opposed to language) maturity. One of the first replies to the
    original post was "Have you tried this with GCCGO?" You might want to do
    that...


    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski <mirtc...@gmail.com<javascript:>>
    wrote:
    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on today's
    internet. you saw what happened in the reddit thread: negativity and
    outright dismissal without even considering that the point was not to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the direct
    comparison with C++, yet most people still latched only on that).
    I know this is not Go's target market (I guess), but why shouldn't it
    be
    the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most" programming
    language in many categories. simplicity, clarity, and generality are
    the key to Go, and I'd be reluctant to give them up for a minute
    improvement in a contrived microbenchmark. besides, I think your
    program is impressively fast as it is.

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



    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>| +1
    650-335-5765

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


    --

    gustavo @ http://niemeyer.net
    --
    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.
  • Karan Misra at Oct 5, 2013 at 3:10 am
    That would be a very interesting question to answer... but I guess the
    property which makes go such a nice language to read/understand will stand
    against it as well.

    I have also rerun the benchmarks again with C++ multi-threading and further
    optimizations: https://kidoman.com/programming/go-getter-part-3.html

    Having a hard time getting a decent run out of *gccgo*. It is slower back a
    factor of 5 (gcc 4.8.1) when compared to go 1.2rc1 for the latest version
    of gorays
    On Friday, October 4, 2013 8:01:47 AM UTC+5:30, Kevin Gillette wrote:

    Agreed. I've no doubt that the original could have been much more highly
    optimized, but for example, manual loop unrolling would be contrary to the
    goal of getting the most functional value per unit of code volume; as soon
    as we expanded the code beyond (un-gofmt'd, minified) business-card size,
    the comparison to the original is moot.

    How efficient and functional can we get a Go raytracer, at an
    equivalent-to-original text display size, when restricted to the size of a
    business card?
    On Thursday, October 3, 2013 11:05:17 AM UTC-6, Gustavo Niemeyer wrote:

    Not to mention the original code was optimized to be printed on a
    business card. A ray tracer on a business card. Hard to beat.
    On Wed, Oct 2, 2013 at 10:05 PM, Michael Jones wrote:
    C compilers are very good. At some point you are simply benchmarking
    compiler (as opposed to language) maturity. One of the first replies to the
    original post was "Have you tried this with GCCGO?" You might want to do
    that...


    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski <mirtc...@gmail.com>
    wrote:
    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on today's
    internet. you saw what happened in the reddit thread: negativity and
    outright dismissal without even considering that the point was not to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the direct
    comparison with C++, yet most people still latched only on that).
    I know this is not Go's target market (I guess), but why shouldn't
    it be
    the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most" programming
    language in many categories. simplicity, clarity, and generality are
    the key to Go, and I'd be reluctant to give them up for a minute
    improvement in a contrived microbenchmark. besides, I think your
    program is impressively fast as it is.

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



    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765

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


    --

    gustavo @ http://niemeyer.net
    --
    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.
  • Michael Jones at Oct 5, 2013 at 4:24 am
    Good work, Karan. You've learned much about fitting a tiny program to Go's
    metaphors. I am concerned about the gccgo performance. It should be 10%
    better at least. May be a MP structure problem. Would not be surprised
    since your scaling us sublinear for such an easily parallelizable task.
    On Oct 4, 2013 8:10 PM, "Karan Misra" wrote:

    That would be a very interesting question to answer... but I guess the
    property which makes go such a nice language to read/understand will stand
    against it as well.

    I have also rerun the benchmarks again with C++ multi-threading and
    further optimizations:
    https://kidoman.com/programming/go-getter-part-3.html

    Having a hard time getting a decent run out of *gccgo*. It is slower back
    a factor of 5 (gcc 4.8.1) when compared to go 1.2rc1 for the latest version
    of gorays
    On Friday, October 4, 2013 8:01:47 AM UTC+5:30, Kevin Gillette wrote:

    Agreed. I've no doubt that the original could have been much more highly
    optimized, but for example, manual loop unrolling would be contrary to the
    goal of getting the most functional value per unit of code volume; as soon
    as we expanded the code beyond (un-gofmt'd, minified) business-card size,
    the comparison to the original is moot.

    How efficient and functional can we get a Go raytracer, at an
    equivalent-to-original text display size, when restricted to the size of a
    business card?
    On Thursday, October 3, 2013 11:05:17 AM UTC-6, Gustavo Niemeyer wrote:

    Not to mention the original code was optimized to be printed on a
    business card. A ray tracer on a business card. Hard to beat.
    On Wed, Oct 2, 2013 at 10:05 PM, Michael Jones wrote:
    C compilers are very good. At some point you are simply benchmarking
    compiler (as opposed to language) maturity. One of the first replies to the
    original post was "Have you tried this with GCCGO?" You might want to do
    that...


    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski <mirtc...@gmail.com>
    wrote:
    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on today's
    internet. you saw what happened in the reddit thread: negativity and
    outright dismissal without even considering that the point was not to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the direct
    comparison with C++, yet most people still latched only on that).
    I know this is not Go's target market (I guess), but why shouldn't
    it be
    the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most" programming
    language in many categories. simplicity, clarity, and generality are
    the key to Go, and I'd be reluctant to give them up for a minute
    improvement in a contrived microbenchmark. besides, I think your
    program is impressively fast as it is.

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



    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765

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



    --

    gustavo @ http://niemeyer.net
    --
    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.
  • Karan Misra at Oct 10, 2013 at 6:04 am
    Let me try to see the scaling using real cores. I had run my tests on a
    2600, which has 4 real cores and 4 HT cores. That would definitely the
    scalability.
    On Saturday, October 5, 2013 9:54:33 AM UTC+5:30, Michael Jones wrote:

    Good work, Karan. You've learned much about fitting a tiny program to Go's
    metaphors. I am concerned about the gccgo performance. It should be 10%
    better at least. May be a MP structure problem. Would not be surprised
    since your scaling us sublinear for such an easily parallelizable task.
    On Oct 4, 2013 8:10 PM, "Karan Misra" <kid...@gmail.com <javascript:>>
    wrote:
    That would be a very interesting question to answer... but I guess the
    property which makes go such a nice language to read/understand will stand
    against it as well.

    I have also rerun the benchmarks again with C++ multi-threading and
    further optimizations:
    https://kidoman.com/programming/go-getter-part-3.html

    Having a hard time getting a decent run out of *gccgo*. It is slower
    back a factor of 5 (gcc 4.8.1) when compared to go 1.2rc1 for the latest
    version of gorays
    On Friday, October 4, 2013 8:01:47 AM UTC+5:30, Kevin Gillette wrote:

    Agreed. I've no doubt that the original could have been much more highly
    optimized, but for example, manual loop unrolling would be contrary to the
    goal of getting the most functional value per unit of code volume; as soon
    as we expanded the code beyond (un-gofmt'd, minified) business-card size,
    the comparison to the original is moot.

    How efficient and functional can we get a Go raytracer, at an
    equivalent-to-original text display size, when restricted to the size of a
    business card?
    On Thursday, October 3, 2013 11:05:17 AM UTC-6, Gustavo Niemeyer wrote:

    Not to mention the original code was optimized to be printed on a
    business card. A ray tracer on a business card. Hard to beat.

    On Wed, Oct 2, 2013 at 10:05 PM, Michael Jones <m...@google.com>
    wrote:
    C compilers are very good. At some point you are simply benchmarking
    compiler (as opposed to language) maturity. One of the first replies to the
    original post was "Have you tried this with GCCGO?" You might want to do
    that...


    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski <
    mirtc...@gmail.com>
    wrote:
    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on today's
    internet. you saw what happened in the reddit thread: negativity and
    outright dismissal without even considering that the point was not
    to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the direct
    comparison with C++, yet most people still latched only on that).
    I know this is not Go's target market (I guess), but why shouldn't
    it be
    the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most" programming
    language in many categories. simplicity, clarity, and generality are
    the key to Go, and I'd be reluctant to give them up for a minute
    improvement in a contrived microbenchmark. besides, I think your
    program is impressively fast as it is.

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



    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765

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



    --

    gustavo @ http://niemeyer.net
    --
    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.
  • Michael Jones at Oct 10, 2013 at 6:15 am
    Try it with 2x the hyperthreaded total:

    4 cpus + 4 HT cpus, try GOMAXPROCS=16

    That tends to be optimum for me.

    On Wed, Oct 9, 2013 at 11:04 PM, Karan Misra wrote:

    Let me try to see the scaling using real cores. I had run my tests on a
    2600, which has 4 real cores and 4 HT cores. That would definitely the
    scalability.

    On Saturday, October 5, 2013 9:54:33 AM UTC+5:30, Michael Jones wrote:

    Good work, Karan. You've learned much about fitting a tiny program to
    Go's metaphors. I am concerned about the gccgo performance. It should be
    10% better at least. May be a MP structure problem. Would not be surprised
    since your scaling us sublinear for such an easily parallelizable task.
    On Oct 4, 2013 8:10 PM, "Karan Misra" wrote:

    That would be a very interesting question to answer... but I guess the
    property which makes go such a nice language to read/understand will stand
    against it as well.

    I have also rerun the benchmarks again with C++ multi-threading and
    further optimizations: https://**kidoman.com/programming/go-**
    getter-part-3.html<https://kidoman.com/programming/go-getter-part-3.html>

    Having a hard time getting a decent run out of *gccgo*. It is slower
    back a factor of 5 (gcc 4.8.1) when compared to go 1.2rc1 for the latest
    version of gorays
    On Friday, October 4, 2013 8:01:47 AM UTC+5:30, Kevin Gillette wrote:

    Agreed. I've no doubt that the original could have been much more
    highly optimized, but for example, manual loop unrolling would be contrary
    to the goal of getting the most functional value per unit of code volume;
    as soon as we expanded the code beyond (un-gofmt'd, minified) business-card
    size, the comparison to the original is moot.

    How efficient and functional can we get a Go raytracer, at an
    equivalent-to-original text display size, when restricted to the size of a
    business card?
    On Thursday, October 3, 2013 11:05:17 AM UTC-6, Gustavo Niemeyer wrote:

    Not to mention the original code was optimized to be printed on a
    business card. A ray tracer on a business card. Hard to beat.

    On Wed, Oct 2, 2013 at 10:05 PM, Michael Jones <m...@google.com>
    wrote:
    C compilers are very good. At some point you are simply benchmarking
    compiler (as opposed to language) maturity. One of the first replies to the
    original post was "Have you tried this with GCCGO?" You might want to do
    that...


    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski <
    mirtc...@gmail.com>
    wrote:
    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on today's
    internet. you saw what happened in the reddit thread: negativity
    and
    outright dismissal without even considering that the point was not
    to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the direct
    comparison with C++, yet most people still latched only on that).
    I know this is not Go's target market (I guess), but why
    shouldn't it be
    the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most" programming
    language in many categories. simplicity, clarity, and generality
    are
    the key to Go, and I'd be reluctant to give them up for a minute
    improvement in a contrived microbenchmark. besides, I think your
    program is impressively fast as it is.

    --
    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.**co**m.
    For more options, visit https://groups.google.com/**grou**
    ps/opt_out <https://groups.google.com/groups/opt_out>.



    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765

    --
    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.**co**m.
    For more options, visit https://groups.google.com/**grou**ps/opt_out<https://groups.google.com/groups/opt_out>.



    --

    gustavo @ http://niemeyer.net
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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.
  • Karan Misra at Oct 10, 2013 at 6:32 am
    For such a CPU intensive activity (the entire CPU maxes out currently with
    GOMAXPROCS=9) would increasing GOMAXPROCS to 16 help?

    Regards,
    Karan 'kid0m4n' Misra

    *CEO, Erodov Media Pvt Ltd*
    Phone: +91 809 555 0069
    Website: *www.erodov.com* <http://www.erodov.com>

    On Thu, Oct 10, 2013 at 11:45 AM, Michael Jones wrote:

    Try it with 2x the hyperthreaded total:

    4 cpus + 4 HT cpus, try GOMAXPROCS=16

    That tends to be optimum for me.

    On Wed, Oct 9, 2013 at 11:04 PM, Karan Misra wrote:

    Let me try to see the scaling using real cores. I had run my tests on a
    2600, which has 4 real cores and 4 HT cores. That would definitely the
    scalability.

    On Saturday, October 5, 2013 9:54:33 AM UTC+5:30, Michael Jones wrote:

    Good work, Karan. You've learned much about fitting a tiny program to
    Go's metaphors. I am concerned about the gccgo performance. It should be
    10% better at least. May be a MP structure problem. Would not be surprised
    since your scaling us sublinear for such an easily parallelizable task.
    On Oct 4, 2013 8:10 PM, "Karan Misra" wrote:

    That would be a very interesting question to answer... but I guess the
    property which makes go such a nice language to read/understand will stand
    against it as well.

    I have also rerun the benchmarks again with C++ multi-threading and
    further optimizations: https://**kidoman.com/programming/go-**
    getter-part-3.html<https://kidoman.com/programming/go-getter-part-3.html>

    Having a hard time getting a decent run out of *gccgo*. It is slower
    back a factor of 5 (gcc 4.8.1) when compared to go 1.2rc1 for the latest
    version of gorays
    On Friday, October 4, 2013 8:01:47 AM UTC+5:30, Kevin Gillette wrote:

    Agreed. I've no doubt that the original could have been much more
    highly optimized, but for example, manual loop unrolling would be contrary
    to the goal of getting the most functional value per unit of code volume;
    as soon as we expanded the code beyond (un-gofmt'd, minified) business-card
    size, the comparison to the original is moot.

    How efficient and functional can we get a Go raytracer, at an
    equivalent-to-original text display size, when restricted to the size of a
    business card?
    On Thursday, October 3, 2013 11:05:17 AM UTC-6, Gustavo Niemeyer wrote:

    Not to mention the original code was optimized to be printed on a
    business card. A ray tracer on a business card. Hard to beat.

    On Wed, Oct 2, 2013 at 10:05 PM, Michael Jones <m...@google.com>
    wrote:
    C compilers are very good. At some point you are simply
    benchmarking
    compiler (as opposed to language) maturity. One of the first
    replies to the
    original post was "Have you tried this with GCCGO?" You might want to do
    that...


    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski <
    mirtc...@gmail.com>
    wrote:
    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on today's
    internet. you saw what happened in the reddit thread: negativity
    and
    outright dismissal without even considering that the point was not
    to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the direct
    comparison with C++, yet most people still latched only on that).
    I know this is not Go's target market (I guess), but why
    shouldn't it be
    the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most" programming
    language in many categories. simplicity, clarity, and generality
    are
    the key to Go, and I'd be reluctant to give them up for a minute
    improvement in a contrived microbenchmark. besides, I think your
    program is impressively fast as it is.

    --
    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.**co**m.
    For more options, visit https://groups.google.com/**grou**
    ps/opt_out <https://groups.google.com/groups/opt_out>.



    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765

    --
    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.**co**m.
    For more options, visit https://groups.google.com/**grou**
    ps/opt_out <https://groups.google.com/groups/opt_out>.



    --

    gustavo @ http://niemeyer.net
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765
    --
    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.
  • Michael Jones at Oct 10, 2013 at 1:35 pm
    It should not. I knew that would be a contentious email. But it seems to
    help my programs...

    On Wed, Oct 9, 2013 at 11:31 PM, Karan Misra wrote:

    For such a CPU intensive activity (the entire CPU maxes out currently with
    GOMAXPROCS=9) would increasing GOMAXPROCS to 16 help?

    Regards,
    Karan 'kid0m4n' Misra

    *CEO, Erodov Media Pvt Ltd*
    Phone: +91 809 555 0069
    Website: *www.erodov.com* <http://www.erodov.com>

    On Thu, Oct 10, 2013 at 11:45 AM, Michael Jones wrote:

    Try it with 2x the hyperthreaded total:

    4 cpus + 4 HT cpus, try GOMAXPROCS=16

    That tends to be optimum for me.

    On Wed, Oct 9, 2013 at 11:04 PM, Karan Misra wrote:

    Let me try to see the scaling using real cores. I had run my tests on
    a 2600, which has 4 real cores and 4 HT cores. That would definitely the
    scalability.

    On Saturday, October 5, 2013 9:54:33 AM UTC+5:30, Michael Jones wrote:

    Good work, Karan. You've learned much about fitting a tiny program to
    Go's metaphors. I am concerned about the gccgo performance. It should be
    10% better at least. May be a MP structure problem. Would not be surprised
    since your scaling us sublinear for such an easily parallelizable task.
    On Oct 4, 2013 8:10 PM, "Karan Misra" wrote:

    That would be a very interesting question to answer... but I guess the
    property which makes go such a nice language to read/understand will stand
    against it as well.

    I have also rerun the benchmarks again with C++ multi-threading and
    further optimizations: https://**kidoman.com/programming/go-**
    getter-part-3.html<https://kidoman.com/programming/go-getter-part-3.html>

    Having a hard time getting a decent run out of *gccgo*. It is slower
    back a factor of 5 (gcc 4.8.1) when compared to go 1.2rc1 for the latest
    version of gorays
    On Friday, October 4, 2013 8:01:47 AM UTC+5:30, Kevin Gillette wrote:

    Agreed. I've no doubt that the original could have been much more
    highly optimized, but for example, manual loop unrolling would be contrary
    to the goal of getting the most functional value per unit of code volume;
    as soon as we expanded the code beyond (un-gofmt'd, minified) business-card
    size, the comparison to the original is moot.

    How efficient and functional can we get a Go raytracer, at an
    equivalent-to-original text display size, when restricted to the size of a
    business card?

    On Thursday, October 3, 2013 11:05:17 AM UTC-6, Gustavo Niemeyer
    wrote:
    Not to mention the original code was optimized to be printed on a
    business card. A ray tracer on a business card. Hard to beat.

    On Wed, Oct 2, 2013 at 10:05 PM, Michael Jones <m...@google.com>
    wrote:
    C compilers are very good. At some point you are simply
    benchmarking
    compiler (as opposed to language) maturity. One of the first
    replies to the
    original post was "Have you tried this with GCCGO?" You might want to do
    that...


    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski <
    mirtc...@gmail.com>
    wrote:
    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on
    today's
    internet. you saw what happened in the reddit thread: negativity
    and
    outright dismissal without even considering that the point was
    not to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the direct
    comparison with C++, yet most people still latched only on that).
    I know this is not Go's target market (I guess), but why
    shouldn't it be
    the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most"
    programming
    language in many categories. simplicity, clarity, and generality
    are
    the key to Go, and I'd be reluctant to give them up for a minute
    improvement in a contrived microbenchmark. besides, I think your
    program is impressively fast as it is.

    --
    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.**co**m.
    For more options, visit https://groups.google.com/**grou**
    ps/opt_out <https://groups.google.com/groups/opt_out>.



    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765

    --
    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.**co**m.
    For more options, visit https://groups.google.com/**grou**
    ps/opt_out <https://groups.google.com/groups/opt_out>.



    --

    gustavo @ http://niemeyer.net
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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.
  • Job van der Zwan at Oct 12, 2013 at 9:17 am
    Any ideas why? Load balancing?
    On Thursday, 10 October 2013 15:34:59 UTC+2, Michael Jones wrote:

    It should not. I knew that would be a contentious email. But it seems to
    help my programs...


    On Wed, Oct 9, 2013 at 11:31 PM, Karan Misra <kid...@gmail.com<javascript:>
    wrote:
    For such a CPU intensive activity (the entire CPU maxes out currently
    with GOMAXPROCS=9) would increasing GOMAXPROCS to 16 help?

    Regards,
    Karan 'kid0m4n' Misra

    *CEO, Erodov Media Pvt Ltd*
    Phone: +91 809 555 0069
    Website: *www.erodov.com* <http://www.erodov.com>


    On Thu, Oct 10, 2013 at 11:45 AM, Michael Jones <m...@google.com<javascript:>
    wrote:
    Try it with 2x the hyperthreaded total:

    4 cpus + 4 HT cpus, try GOMAXPROCS=16

    That tends to be optimum for me.


    On Wed, Oct 9, 2013 at 11:04 PM, Karan Misra <kid...@gmail.com<javascript:>
    wrote:
    Let me try to see the scaling using real cores. I had run my tests on
    a 2600, which has 4 real cores and 4 HT cores. That would definitely the
    scalability.

    On Saturday, October 5, 2013 9:54:33 AM UTC+5:30, Michael Jones wrote:

    Good work, Karan. You've learned much about fitting a tiny program to
    Go's metaphors. I am concerned about the gccgo performance. It should be
    10% better at least. May be a MP structure problem. Would not be surprised
    since your scaling us sublinear for such an easily parallelizable task.
    On Oct 4, 2013 8:10 PM, "Karan Misra" wrote:

    That would be a very interesting question to answer... but I guess
    the property which makes go such a nice language to read/understand will
    stand against it as well.

    I have also rerun the benchmarks again with C++ multi-threading and
    further optimizations: https://**kidoman.com/programming/go-**
    getter-part-3.html<https://kidoman.com/programming/go-getter-part-3.html>

    Having a hard time getting a decent run out of *gccgo*. It is slower
    back a factor of 5 (gcc 4.8.1) when compared to go 1.2rc1 for the latest
    version of gorays
    On Friday, October 4, 2013 8:01:47 AM UTC+5:30, Kevin Gillette wrote:

    Agreed. I've no doubt that the original could have been much more
    highly optimized, but for example, manual loop unrolling would be contrary
    to the goal of getting the most functional value per unit of code volume;
    as soon as we expanded the code beyond (un-gofmt'd, minified) business-card
    size, the comparison to the original is moot.

    How efficient and functional can we get a Go raytracer, at an
    equivalent-to-original text display size, when restricted to the size of a
    business card?

    On Thursday, October 3, 2013 11:05:17 AM UTC-6, Gustavo Niemeyer
    wrote:
    Not to mention the original code was optimized to be printed on a
    business card. A ray tracer on a business card. Hard to beat.

    On Wed, Oct 2, 2013 at 10:05 PM, Michael Jones <m...@google.com>
    wrote:
    C compilers are very good. At some point you are simply
    benchmarking
    compiler (as opposed to language) maturity. One of the first
    replies to the
    original post was "Have you tried this with GCCGO?" You might
    want to do
    that...


    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski <
    mirtc...@gmail.com>
    wrote:
    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on
    today's
    internet. you saw what happened in the reddit thread: negativity
    and
    outright dismissal without even considering that the point was
    not to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the
    direct
    comparison with C++, yet most people still latched only on
    that).
    I know this is not Go's target market (I guess), but why
    shouldn't it be
    the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most"
    programming
    language in many categories. simplicity, clarity, and generality
    are
    the key to Go, and I'd be reluctant to give them up for a minute
    improvement in a contrived microbenchmark. besides, I think your
    program is impressively fast as it is.

    --
    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.**co**m.
    For more options, visit https://groups.google.com/**grou**
    ps/opt_out <https://groups.google.com/groups/opt_out>.



    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com| +1
    650-335-5765

    --
    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.**co**m.
    For more options, visit https://groups.google.com/**grou**
    ps/opt_out <https://groups.google.com/groups/opt_out>.



    --

    gustavo @ http://niemeyer.net
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>
    +1 650-335-5765

    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>
    +1 650-335-5765
    --
    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.
  • Michael Jones at Oct 12, 2013 at 1:54 pm
    No. Feel free to disregard my anecdotal evidence. Maybe it is just
    something about my Mac's (OS X's) processor management properties.


    On Sat, Oct 12, 2013 at 2:17 AM, Job van der Zwan
    wrote:
    Any ideas why? Load balancing?

    On Thursday, 10 October 2013 15:34:59 UTC+2, Michael Jones wrote:

    It should not. I knew that would be a contentious email. But it seems to
    help my programs...

    On Wed, Oct 9, 2013 at 11:31 PM, Karan Misra wrote:

    For such a CPU intensive activity (the entire CPU maxes out currently
    with GOMAXPROCS=9) would increasing GOMAXPROCS to 16 help?

    Regards,
    Karan 'kid0m4n' Misra

    *CEO, Erodov Media Pvt Ltd*
    Phone: +91 809 555 0069
    Website: *www.erodov.com* <http://www.erodov.com>

    On Thu, Oct 10, 2013 at 11:45 AM, Michael Jones wrote:

    Try it with 2x the hyperthreaded total:

    4 cpus + 4 HT cpus, try GOMAXPROCS=16

    That tends to be optimum for me.

    On Wed, Oct 9, 2013 at 11:04 PM, Karan Misra wrote:

    Let me try to see the scaling using real cores. I had run my tests
    on a 2600, which has 4 real cores and 4 HT cores. That would definitely the
    scalability.

    On Saturday, October 5, 2013 9:54:33 AM UTC+5:30, Michael Jones wrote:

    Good work, Karan. You've learned much about fitting a tiny program to
    Go's metaphors. I am concerned about the gccgo performance. It should be
    10% better at least. May be a MP structure problem. Would not be surprised
    since your scaling us sublinear for such an easily parallelizable task.
    On Oct 4, 2013 8:10 PM, "Karan Misra" wrote:

    That would be a very interesting question to answer... but I guess
    the property which makes go such a nice language to read/understand will
    stand against it as well.

    I have also rerun the benchmarks again with C++ multi-threading and
    further optimizations: https://**kidoman**.com/programming/go-**
    getter-**part-3.html<https://kidoman.com/programming/go-getter-part-3.html>

    Having a hard time getting a decent run out of *gccgo*. It is
    slower back a factor of 5 (gcc 4.8.1) when compared to go 1.2rc1 for the
    latest version of gorays
    On Friday, October 4, 2013 8:01:47 AM UTC+5:30, Kevin Gillette wrote:

    Agreed. I've no doubt that the original could have been much more
    highly optimized, but for example, manual loop unrolling would be contrary
    to the goal of getting the most functional value per unit of code volume;
    as soon as we expanded the code beyond (un-gofmt'd, minified) business-card
    size, the comparison to the original is moot.

    How efficient and functional can we get a Go raytracer, at an
    equivalent-to-original text display size, when restricted to the size of a
    business card?

    On Thursday, October 3, 2013 11:05:17 AM UTC-6, Gustavo Niemeyer
    wrote:
    Not to mention the original code was optimized to be printed on a
    business card. A ray tracer on a business card. Hard to beat.

    On Wed, Oct 2, 2013 at 10:05 PM, Michael Jones <m...@google.com>
    wrote:
    C compilers are very good. At some point you are simply
    benchmarking
    compiler (as opposed to language) maturity. One of the first
    replies to the
    original post was "Have you tried this with GCCGO?" You might
    want to do
    that...


    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski <
    mirtc...@gmail.com>
    wrote:
    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on
    today's
    internet. you saw what happened in the reddit thread:
    negativity and
    outright dismissal without even considering that the point was
    not to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the
    direct
    comparison with C++, yet most people still latched only on
    that).
    I know this is not Go's target market (I guess), but why
    shouldn't it be
    the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most"
    programming
    language in many categories. simplicity, clarity, and
    generality are
    the key to Go, and I'd be reluctant to give them up for a
    minute
    improvement in a contrived microbenchmark. besides, I think
    your
    program is impressively fast as it is.

    --
    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.**co****m.
    For more options, visit https://groups.google.com/**grou****
    ps/opt_out <https://groups.google.com/groups/opt_out>.



    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com| +1
    650-335-5765

    --
    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.**co****m.
    For more options, visit https://groups.google.com/**grou****
    ps/opt_out <https://groups.google.com/groups/opt_out>.



    --

    gustavo @ http://niemeyer.net
    --
    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>
    .


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765

    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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.
  • Job van der Zwan at Oct 12, 2013 at 3:17 pm
    Well, if the difference pops up consistently, wouldn't finding the minimal
    algorithm that reproduces the quirk be useful feedback for the people
    working on the scheduler, for example?
    On Saturday, 12 October 2013 15:53:54 UTC+2, Michael Jones wrote:

    No. Feel free to disregard my anecdotal evidence. Maybe it is just
    something about my Mac's (OS X's) processor management properties.


    On Sat, Oct 12, 2013 at 2:17 AM, Job van der Zwan <j.l.van...@gmail.com<javascript:>
    wrote:
    Any ideas why? Load balancing?

    On Thursday, 10 October 2013 15:34:59 UTC+2, Michael Jones wrote:

    It should not. I knew that would be a contentious email. But it seems to
    help my programs...

    On Wed, Oct 9, 2013 at 11:31 PM, Karan Misra wrote:

    For such a CPU intensive activity (the entire CPU maxes out currently
    with GOMAXPROCS=9) would increasing GOMAXPROCS to 16 help?

    Regards,
    Karan 'kid0m4n' Misra

    *CEO, Erodov Media Pvt Ltd*
    Phone: +91 809 555 0069
    Website: *www.erodov.com* <http://www.erodov.com>

    On Thu, Oct 10, 2013 at 11:45 AM, Michael Jones wrote:

    Try it with 2x the hyperthreaded total:

    4 cpus + 4 HT cpus, try GOMAXPROCS=16

    That tends to be optimum for me.

    On Wed, Oct 9, 2013 at 11:04 PM, Karan Misra wrote:

    Let me try to see the scaling using real cores. I had run my tests
    on a 2600, which has 4 real cores and 4 HT cores. That would definitely the
    scalability.

    On Saturday, October 5, 2013 9:54:33 AM UTC+5:30, Michael Jones wrote:

    Good work, Karan. You've learned much about fitting a tiny program
    to Go's metaphors. I am concerned about the gccgo performance. It should be
    10% better at least. May be a MP structure problem. Would not be surprised
    since your scaling us sublinear for such an easily parallelizable task.
    On Oct 4, 2013 8:10 PM, "Karan Misra" wrote:

    That would be a very interesting question to answer... but I guess
    the property which makes go such a nice language to read/understand will
    stand against it as well.

    I have also rerun the benchmarks again with C++ multi-threading and
    further optimizations: https://**kidoman**.com/programming/go-**
    getter-**part-3.html<https://kidoman.com/programming/go-getter-part-3.html>

    Having a hard time getting a decent run out of *gccgo*. It is
    slower back a factor of 5 (gcc 4.8.1) when compared to go 1.2rc1 for the
    latest version of gorays

    On Friday, October 4, 2013 8:01:47 AM UTC+5:30, Kevin Gillette
    wrote:
    Agreed. I've no doubt that the original could have been much more
    highly optimized, but for example, manual loop unrolling would be contrary
    to the goal of getting the most functional value per unit of code volume;
    as soon as we expanded the code beyond (un-gofmt'd, minified) business-card
    size, the comparison to the original is moot.

    How efficient and functional can we get a Go raytracer, at an
    equivalent-to-original text display size, when restricted to the size of a
    business card?

    On Thursday, October 3, 2013 11:05:17 AM UTC-6, Gustavo Niemeyer
    wrote:
    Not to mention the original code was optimized to be printed on a
    business card. A ray tracer on a business card. Hard to beat.

    On Wed, Oct 2, 2013 at 10:05 PM, Michael Jones <m...@google.com>
    wrote:
    C compilers are very good. At some point you are simply
    benchmarking
    compiler (as opposed to language) maturity. One of the first
    replies to the
    original post was "Have you tried this with GCCGO?" You might
    want to do
    that...


    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski <
    mirtc...@gmail.com>
    wrote:
    In my opinion, there's no point in optimizing unless you have
    a
    particular goal in mind. this is not a game you can win on
    today's
    internet. you saw what happened in the reddit thread:
    negativity and
    outright dismissal without even considering that the point was
    not to
    compare two languages, but to learn how to optimize one of
    them
    (that's why the title was worded in a way that avoided the
    direct
    comparison with C++, yet most people still latched only on
    that).
    I know this is not Go's target market (I guess), but why
    shouldn't it be
    the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most"
    programming
    language in many categories. simplicity, clarity, and
    generality are
    the key to Go, and I'd be reluctant to give them up for a
    minute
    improvement in a contrived microbenchmark. besides, I think
    your
    program is impressively fast as it is.

    --
    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.**co****m.
    For more options, visit https://groups.google.com/**grou****
    ps/opt_out <https://groups.google.com/groups/opt_out>.



    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com| +1
    650-335-5765

    --
    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.**co****m.
    For more options, visit https://groups.google.com/**grou****
    ps/opt_out <https://groups.google.com/groups/opt_out>.



    --

    gustavo @ http://niemeyer.net
    --
    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>
    .


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765

    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>
    +1 650-335-5765
    --
    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.
  • Atomly at Oct 14, 2013 at 4:20 pm

    On Thu, Oct 10, 2013 at 9:34 AM, Michael Jones wrote:

    I knew that would be a contentious email.
    Pardon the pun. :P

    :: atomly ::

    [ atomly@atomly.com : www.atomly.com : http://blog.atomly.com/ ...
    [ atomiq records : new york city : +1.347.692.8661 ...
    [ e-mail atomly-news-subscribe@atomly.com for atomly info and updates ...


    On Wed, Oct 9, 2013 at 11:31 PM, Karan Misra wrote:

    For such a CPU intensive activity (the entire CPU maxes out currently
    with GOMAXPROCS=9) would increasing GOMAXPROCS to 16 help?

    Regards,
    Karan 'kid0m4n' Misra

    *CEO, Erodov Media Pvt Ltd*
    Phone: +91 809 555 0069
    Website: *www.erodov.com* <http://www.erodov.com>

    On Thu, Oct 10, 2013 at 11:45 AM, Michael Jones wrote:

    Try it with 2x the hyperthreaded total:

    4 cpus + 4 HT cpus, try GOMAXPROCS=16

    That tends to be optimum for me.

    On Wed, Oct 9, 2013 at 11:04 PM, Karan Misra wrote:

    Let me try to see the scaling using real cores. I had run my tests on
    a 2600, which has 4 real cores and 4 HT cores. That would definitely the
    scalability.

    On Saturday, October 5, 2013 9:54:33 AM UTC+5:30, Michael Jones wrote:

    Good work, Karan. You've learned much about fitting a tiny program to
    Go's metaphors. I am concerned about the gccgo performance. It should be
    10% better at least. May be a MP structure problem. Would not be surprised
    since your scaling us sublinear for such an easily parallelizable task.
    On Oct 4, 2013 8:10 PM, "Karan Misra" wrote:

    That would be a very interesting question to answer... but I guess
    the property which makes go such a nice language to read/understand will
    stand against it as well.

    I have also rerun the benchmarks again with C++ multi-threading and
    further optimizations: https://**kidoman.com/programming/go-**
    getter-part-3.html<https://kidoman.com/programming/go-getter-part-3.html>

    Having a hard time getting a decent run out of *gccgo*. It is slower
    back a factor of 5 (gcc 4.8.1) when compared to go 1.2rc1 for the latest
    version of gorays
    On Friday, October 4, 2013 8:01:47 AM UTC+5:30, Kevin Gillette wrote:

    Agreed. I've no doubt that the original could have been much more
    highly optimized, but for example, manual loop unrolling would be contrary
    to the goal of getting the most functional value per unit of code volume;
    as soon as we expanded the code beyond (un-gofmt'd, minified) business-card
    size, the comparison to the original is moot.

    How efficient and functional can we get a Go raytracer, at an
    equivalent-to-original text display size, when restricted to the size of a
    business card?

    On Thursday, October 3, 2013 11:05:17 AM UTC-6, Gustavo Niemeyer
    wrote:
    Not to mention the original code was optimized to be printed on a
    business card. A ray tracer on a business card. Hard to beat.

    On Wed, Oct 2, 2013 at 10:05 PM, Michael Jones <m...@google.com>
    wrote:
    C compilers are very good. At some point you are simply
    benchmarking
    compiler (as opposed to language) maturity. One of the first
    replies to the
    original post was "Have you tried this with GCCGO?" You might
    want to do
    that...


    On Wed, Oct 2, 2013 at 5:56 PM, andrey mirtchovski <
    mirtc...@gmail.com>
    wrote:
    In my opinion, there's no point in optimizing unless you have a
    particular goal in mind. this is not a game you can win on
    today's
    internet. you saw what happened in the reddit thread: negativity
    and
    outright dismissal without even considering that the point was
    not to
    compare two languages, but to learn how to optimize one of them
    (that's why the title was worded in a way that avoided the
    direct
    comparison with C++, yet most people still latched only on
    that).
    I know this is not Go's target market (I guess), but why
    shouldn't it be
    the
    fastest m*f* language out there?
    to many (most?) of its users, Go is already "the most"
    programming
    language in many categories. simplicity, clarity, and generality
    are
    the key to Go, and I'd be reluctant to give them up for a minute
    improvement in a contrived microbenchmark. besides, I think your
    program is impressively fast as it is.

    --
    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.**co**m.
    For more options, visit https://groups.google.com/**grou**
    ps/opt_out <https://groups.google.com/groups/opt_out>.



    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com| +1
    650-335-5765

    --
    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.**co**m.
    For more options, visit https://groups.google.com/**grou**
    ps/opt_out <https://groups.google.com/groups/opt_out>.



    --

    gustavo @ http://niemeyer.net
    --
    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.


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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.
    To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA_Y42xfSLNK8hQcioQehPQG2EfBfhE-_tMyLgZgFucT9JMMsQ%40mail.gmail.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ugorji Nwoke at Oct 3, 2013 at 1:12 am

    On Wednesday, October 2, 2013 8:42:25 PM UTC-4, Karan Misra wrote:
    Guys,

    So I took the plunge and ported over the "optimizations" to C++, and reran
    the benchmarks:

    https://kidoman.com/programming/go-getter-part-2.html

    Your graph on the page above seems mislabeled. It looks like Go is
    fastest.

    --
    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.
  • Karan Misra at Oct 3, 2013 at 1:40 am
    I checked it again. It looks right.

    Go is faster than the unoptimized C++ version and when utilizing > 1 core.

    Sent from my iPhone

    On 03-Oct-2013, at 6:42, Ugorji Nwoke wrote:


    On Wednesday, October 2, 2013 8:42:25 PM UTC-4, Karan Misra wrote:

    Guys,

    So I took the plunge and ported over the "optimizations" to C++, and reran
    the benchmarks:

    https://kidoman.com/programming/go-getter-part-2.html

    Your graph on the page above seems mislabeled. It looks like Go is
    fastest.

    --
    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

People

Translate

site design / logo © 2019 Grokbase