Also, I installed gnu gcc 9.2 and used it rather than the OSX clang, and optimized C++ (-O2) time was 17.9 secs.
> On Feb 12, 2020, at 11:59 PM, robert engels <reng...@ix.netcom.com> wrote: > > 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 >> <mailto: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 >>> <mailto: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 > <mailto: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 > > <https://groups.google.com/d/msgid/golang-nuts/5162AEA4-E03D-4250-BB93-F661659FC5B1%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/6741085E-410F-4FF5-BBF9-644B5CC68FEF%40ix.netcom.com.
