8 Jun
2020
8 Jun
'20
8:14 p.m.
On 6/8/20, Dan Cross <crossd(a)gmail.com> wrote:
[ -TUHS and +COFF ]
On Mon, Jun 8, 2020 at 1:49 AM Lars Brinkhoff <lars(a)nocrew.org> wrote:
The real question is can Go be really faster than C/C++? The last
time I checked it was at least two times slower on an average. Plus
it will not run on older systems; I think you need at least kernel
2.6.23 and its executables are rather big compared to C. In the
beginning it was fun to create some clones of classic Unix tools in
Go, but in reality they were still slower and bigger than the original
utilities.
I jumped on the Go bandwagon in 2010 (like a lot of people from the
open source community) but recently I find myself coming back more and
more to C. It is still a superior language in almost all areas. Plus
it works on everything from retro 8-bit micros to modern big HPC
systems.
--Andy
Chris Torek wrote:
I worked on a big system written in Common Lisp at one point, and it used a
pretty standard Lispy garbage collector. It spent something like 15% of its
time in GC. It was sufficiently bad that we forced a full GC between every
query.
The Go garbage collector, on the other hand, is really neat. I believe it
reserves something like 25% of available CPU time for itself, but it runs
concurrently with your program: having to stop the world for GC is very,
very rare in Go programs and even when you have to do it, the concurrent
code (which, by the way, can make use of full physical parallelism on
multicore systems) has already done much of the heavy lifting, meaning you
spend less time in a GC pause. It's a very impressive piece of engineering.
You pay (sometimes noticeably) for the GC, but
the price is not
too bad in less time-critical situations. The GC has a few short
stop-the-world points but since Go 1.6 or so, it's pretty smooth,
unlike what I remember from 1980s Lisp systems. :-)
I'm guessing those 1980s Lisp systems would also be pretty smooth on
2020s hardware.