Here is some pretty indisputable evidence on the advancements of GC/JVM vs C++.
See this paper/project https://github.com/hundt98847/multi-language-bench <https://github.com/hundt98847/multi-language-bench> that was done by Google in 2011. If you read the paper, the C++ code was tuned by expert C++ programmers at Google. The java_pro author version refused to optimize further - which he felt would create “esoteric non-idomatic” Java. The paper reports that the C++ code outperformed java_pro by 4x - 12x, and go_pro by 5.5x I re-ran the tests using the latest C++ compiler,Go, and Java 13. The code is unchanged since it was posted. Nothing has been modified (Go needed the directory structure changed to compile). Different hardware. Different OS. Different compilers. Different Java runtime. (same JVM settings - so using a different default GC). All tests run on the same OS/hardware. C++ (-O2) = 16.5 secs C++ (-O3) = 16.5 secs go_pro = 19 secs java_pro = 8.4 secs Or Java is almost 2x faster than C++, and Go is nearly the same performance as C++. Run the tests yourself… (easy to do, Makefiles included) JVM/GC has improved DRAMATICALLY in the past 9 years - static compilation/optimization not so much… Stressing again - ZERO CODE CHANGES ! Enjoy ! > On Feb 12, 2020, at 10:17 PM, Robert Engels <reng...@ix.netcom.com> wrote: > > G1GC only went into production with Java 7 in 2011. > > I don’t think you understand how Zing works. Furthermore, malloc based > systems actually have longer pauses especially as things get fragmented. > > I believe your knowledge of modern GC is way out of date. > >> On Feb 12, 2020, at 8:22 PM, alex.besogo...@gmail.com wrote: >> >> >> Nope. G1GC actually dates back to 2004 (see doi 10.1.1.63.6386) with >> Metronome even earlier (2002, I think). >> >> Zing has actually even less throughput than the good old CMS and way more >> memory overhead on massively-parallel systems. However, it does guarantee >> realtime performance that is necessary for high-speed financial apps. >> Shenandoah is similar. >> >> And it's not getting better. On systems with hundreds of CPUs even small >> stop-the-world pauses are unacceptable, but making a pauseless compacting GC >> for a shared-memory system seems to be a fool's errand. By leaving out >> compaction, the benefits of GC become even less appealing. >> >> On Wednesday, February 12, 2020 at 2:57:04 PM UTC-8, Robert Engels wrote: >> GCs have radically improved since then - at least in practical >> implementation. >> >> Again, see G1, Metronome, Zing or Shenandoah - none of these were available >> in 2005. >> >> (Or even Go's GC performance progression - but as I mentioned, in this >> particular test the lack of a generational collector is holding it back). >> >> -----Original Message----- >> From: alex.b...@gmail.com <> >> Sent: Feb 12, 2020 3:06 PM >> To: golang-nuts >> Subject: Re: [go-nuts] Go without garbage collector >> >> I'm very familiar with this paper. It's not the first one that uses oracular >> memory management for comparison, the earlier one used ML as its langauge. >> >> The problem with these papers is that they're using very artificial >> benchmarks, not really representative of real workloads. They additionally >> use languages that are very heap-oriented, with very few value objects. >> >> GCs also have not radically improved since then, if anything they are worse >> now in massively-parallel environment than on single-core CPUs of yore. >> >> On Tuesday, February 11, 2020 at 8:54:29 PM UTC-8, robert engels wrote: >> Here is a paper from 2005 >> https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf >> <https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf> that proves >> otherwise. >> >> GC techniques have radically improved since then, some with hardware >> support, so much so that it is no longer a contest. >> >> To reiterate though, if you don’t have dynamic memory management - which is >> essentially allocate and forget - that will “probably" be faster (many GC >> systems have an extra level of indirection). >> >> You can write robust systems without dynamic memory, but it is very very >> difficult - beyond the skills of most developers. >> >> So most developers resort to dynamic memory at some point - and once you do >> that - GC will crush your manual memory management techniques. >> >>> On Feb 11, 2020, at 10:31 PM, alex.b...@gmail.com <> wrote: >>> >>> Actually, it was not proven. And in practice manual memory management seems >>> to be outperforming GC in majority of cases. >>> >>> On Tuesday, February 11, 2020 at 5:59:26 PM UTC-8, robert engels wrote: >>> It’s been PROVEN that GC outperforms all manual memory management except in >>> EXTREMELY isolated cases (very non-traditional allocation or deallocation >>> patterns). >>> >>> It’s all about constraints and tolerances. >>> >>> You design a “system” that takes both into account - if not, you’re not >>> engineering, you're guessing. >>> >>>> On Feb 11, 2020, at 4:29 AM, deat...@gmail.com <> wrote: >>>> >>>> What about #vlang ? https://vlang.io/ <https://vlang.io/> >>>> >>>> On Sunday, 17 June 2012 22:40:30 UTC+2, nsf wrote: >>>> On Sun, 17 Jun 2012 11:48:53 -0700 (PDT) >>>> ⚛ <0xe2.0...@gmail.com <>> wrote: >>>> >>>> > > You can't have Go syntax without a garbage collector. >>>> > > >>>> > >>>> > I wouldn't be so sure about it. >>>> > >>>> >>>> Let me rephrase myself. When someone says "I want Go without garbage >>>> collection" it means a person wants a feel he has with Go, but at the >>>> same time without garbage collection. At least that's my case. I wanted >>>> exactly that. And you can't have that. You can build a language similar >>>> to Go without GC, but you won't get a feel of Go. At least, I couldn't >>>> do it. And maybe it's kind of obvious, but when there is a need to >>>> manage memory, that factor alone creates a different programmer mindset. >>>> And in my opinion what Go does so well for a programmer is establishing >>>> its own mindset that gives a very nice and smooth development process. >>>> What we call "a feel of Go". >>>> >>>> That's actually very same mistake that leads to talks like "where is my >>>> feature X? I want feature X in your language". And the problem here is >>>> that a language is not just a collection of features, it's a >>>> composition of features. You can't just stick something in and make it >>>> better (see C++) and you can't throw something out. Every feature >>>> addition/removal affects the language as a whole, mutating it to a >>>> different state. And in my opinion GC is a critical feature that allows >>>> you to have memory safety and (well, let's put it that way) memory >>>> safety is one of the major features in Go. >>>> >>>> So.. think about it. "I want Go with templates" and "I want Go without >>>> garbage collection" are very similar things. Both hide the desire of >>>> improving/changing something without realization that this will affect >>>> other areas dramatically. >>>> >>>> And to make a summary: I tried that, I did that mistake thinking you >>>> can build something out of Go just by taking parts you like and mixing >>>> them in some weird way. I was stupid (to make it clear, I'm not >>>> implying that anyone is). Hopefully what I said makes some sense. >>>> >>>> >>>> Offtopic: >>>> >>>> Btw. Thanks for your work on GC precision, I really hope those patches >>>> will get into Go. One of the areas where I want to apply Go is desktop >>>> applications. And for these you need a precise GC, because some desktop >>>> apps have uptime measured in days or weeks (especially on geek's linux >>>> machines) and you clearly don't want to get mozilla's firefox fame for >>>> eating all the memory. >>>> >>>> -- >>>> 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 golan...@googlegroups.com <>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/165ebe92-362d-44f0-9ddb-2e152276b6fc%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/golang-nuts/165ebe92-362d-44f0-9ddb-2e152276b6fc%40googlegroups.com?utm_medium=email&utm_source=footer>. >>> >>> >>> -- >>> 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 golan...@googlegroups.com <>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/c03420c5-d1b0-4c73-8a61-f4fa131018f9%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/c03420c5-d1b0-4c73-8a61-f4fa131018f9%40googlegroups.com?utm_medium=email&utm_source=footer>. >> >> >> -- >> 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 golan...@googlegroups.com <>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/465e2109-e0a5-4fdc-9dbf-5670eb73bfef%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/465e2109-e0a5-4fdc-9dbf-5670eb73bfef%40googlegroups.com?utm_medium=email&utm_source=footer>. >> >> >> >> >> -- >> 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 >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/36d34a8b-435d-4dab-b3b7-3d3471ff7428%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/36d34a8b-435d-4dab-b3b7-3d3471ff7428%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/662CB08C-4A92-4C3C-93E8-5C65A53ACAAD%40ix.netcom.com > > <https://groups.google.com/d/msgid/golang-nuts/662CB08C-4A92-4C3C-93E8-5C65A53ACAAD%40ix.netcom.com?utm_medium=email&utm_source=footer>. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5162AEA4-E03D-4250-BB93-F661659FC5B1%40ix.netcom.com.
