Back on the ground for a bit with speedup news. My first ever performance tuning over Iran turned out well, the 1000000 case formerly...
real 0m1.282s user 0m1.324s sys 0m0.027s ...is now down to real 0m0.868s user 0m0.858s sys 0m0.006s on the same MacBook Pro. I also changed the code to take advantage of the MBPs multiple cores. In that case we get... real 0m0.238s user 0m1.266s sys 0m0.014s for the same results using 4 cores on battery power. I continue to feel good about achievable performance in Go. On Sun, Feb 26, 2017 at 2:19 PM, Jesper Louis Andersen < jesper.louis.ander...@gmail.com> wrote: > On Sun, Feb 26, 2017 at 12:45 PM Éric Jacoboni <eric.jacob...@gmail.com> > wrote: > >> >> Are you sure? When i write age := 20, i don't play with memory index... >> So, i have to write age := int32(20) or var age int32 = 20, which is >> rather boring, imho. >> >> >> >> > It is a trade-off in which you have a couple of options to choose from. Go > picked a 64bit integer. Other options include picking a "bigint" with no > bounds at all, or picking a 32bit integer. > > All of those options have situations where they are good choices, and > situations where they aren't so. Most code is not sensitive to something > like integer division because most code is not sensitive to CPU or Memory > bounds nowadays (the machines are simply too fast). On the other hand, a > 32bit value regularly runs into size constraints because 2 billion tends to > be a fairly small number (the machines are simply too large). > > Haskell and Erlang defaults to the "bigint" solution. This is not without > troubles either. While it removes problems with integer overflows > completely from the language, many external data formats have limits at the > 32bit or 64bit boundary, and you need to be careful when you start dumping > data. JSON, a widely popular format, has its limit at 53 bits, which > creates its own slew of practical problems. Also, fast Haskell code > requires you to be careful about this and tell the system, via types, what > size you want. Fast Erlang code doesn't really exist, and you tend to write > those parts in another language next to it. > > OCaml choses 31bit and 63bit integers respectively. This allows you to > easily tag integers so they are distinguishable from pointers in the GC. In > turn, parametric polymorhpism becomes easier to implement without the need > to whole-program-compile. It also makes integer operations slower since you > have to operate on tagged representations. > > For a modern language, I think Go is doing the right thing. 64bit integers > are large enough that it pushes the boundary for error outwards while > retaining good speed. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Michael T. Jones michael.jo...@gmail.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
