On Wednesday, 12 September 2018 15:47:14 UTC+3, Robert Engels wrote: > > I am well aware of mechanical sympathy and the techniques (like the > disrupter) used (I would counter that in many cases you are not writing > “Java” due to the object pooling ,etc.) > > What I’ve shown is that Java is already more performant than Go without > using those techniques for many application aspects - specifically in terms > of method dispatch, but still Go direct methods vs interface methods are 5x > faster, so you if you need ultra performance critical code you need to keep > that in mind, but RARELY is this the case (except for some people in HFT > but even they have moved on to FPGAs) and you are far better structuring > your code for maintainability and functionality rather than worrying about > slower method dispatch... >
https://www.youtube.com/watch?v=rX0ItVEVjHc > > ArrayList<byte> is not “correct” Java - because you are going to encode > every byte as an object in an object[] behind the scenes, and each would > need to be managed as an Object. Java has arrays, you would simply use a > byte[]. If you need expandable arrays, you would probably use a ByteBuffer. > That is exactly the boxing overhead that the generics dilemma talks about. ByteBuffer is an example where the generics weren't good enough and people ended up manually implemented a specialized version. Remember you shouldn't be comparing performance of Java generics vs Go status quo... you should be comparing Java generics vs C++ generics vs Swift generics vs D generics vs Zig generics. That way the trade-offs of different approaches becomes visible. > > Your point highlights an important consideration - most people don’t know > how to write REALLY performant software in a given language unless it is an > area of focus and experience, which is why I distribute the tests publicly > because I will grant that there may be techniques in Go that I am not > understanding or misusing - but at this point I think I have a pretty good > handle on the internal workings of Go. > I completely agree that most people can live with the current state. > > The biggest performance advantage for Go will be the garbage collector due > to the “value type” of array struct, since there is only a single reference > to be GC managed regardless of the number of elements. That is not possible > in Java - at least not now. That being said, there are Java VMs like Azul > Zing that are far more performant than Go in terms of GC pauses without any > restricting on the layout of the memory being managed. As soon as you start > using array of interface in Go, you are going to put pressure on the GC, as > the number of references that need to be managed expands proportional to > the size of the array - at least I think so - but there may be behind the > scenes escape analysis that determines if any references escape the array, > and if not it can still manage it is a single reference. > > But all of this is off-topic from the original post - which was to suggest > to keep it simple and use interfaces/closures at runtime to support > generics and not worrying about the performance overhead - the really > performance critical coders can always write non-generic/interface > containers if they absolutely think they need it, but most likely they > don’t... > I tend to agree, but having specializing generics makes some of that code easier to manage. > > > On Sep 11, 2018, at 11:57 PM, Egon <egon...@gmail.com <javascript:>> > wrote: > > > > On Tuesday, 11 September 2018 18:28:29 UTC+3, Robert Engels wrote: >> >> >> On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts <golan...@ >> googlegroups.com> wrote: >> >> [golang-nuts to CC, golang-dev to BCC] >> >> On Mon, Sep 10, 2018 at 5:33 PM robert engels <ren...@ix.netcom.com> >> wrote: >> >>> In the entire codebase of Docker I could find only one obvious use of >>> interface{}, and no type casts. >>> >> >> Generics are not only useful for functions taking interface{}. They are >> also useful for functions taking non-empty interfaces, for cases where you >> could re-use an existing generic implementation and forego re-implementing >> it for your concrete type and for reducing boilerplate across many types >> (e.g. the famous sort.Interface). >> >> >> True, and reviewing cockroachdb shows the sort.Interface used a lot, and >> a generic container could avoid that, but in most cases this could be >> solved by only having to implement Less and having ’sort’ work on slices - >> as the vast majority are slices to begin with. >> >> I am just attempting to point out that the original Go designers offered >> ’typed’ collections (slice, map) as part of the language. They fall short >> in some ways but it may be possible for a simpler solution to expand their >> abilities, or add others, without resorting to generics. I like the >> simplicity and readability “no surprises for the most part” of Go, and I >> think it should try to stay that way. >> >> >> In my opinion, Go isn’t suitable for large enterprise systems with >>> million+ lines of code >>> >> >> No offense, but empirically, the existence of such systems written in Go >> seems to contradict you here. Kubernetes has 3.5M lines of code in just the >> single main repository. And that's just open source software - most of the >> actual million+ lines of code systems written in Go you won't know about, >> because they are not open (I work on one of those). >> >> >> This seems to contradict this a bit, >> https://stackoverflow.com/questions/41586501/why-is-kubernetes-source-code-an-order-of-magnitude-larger-than-other-container >> but >> it may be an indictment that Go’s lack of classes/inheritance/generics >> leads to code bloat. I believe that you work on a large Go system, I am >> just not positive it is pleasurable to maintain/refactor - maybe for high >> knowledge original authors - but as I said I am going to leave that >> criticism to another post, as it is not particular germane to the generics >> discussion. >> >> >> The Java generic code is a pleasure to use, and maintain >>> >> >> I believe this is up to individual perception. Personally, I found >> working on a large-scale Java codebase to be an unpleasant experience, >> because of the generic code. >> >> >> I would be curious as to what the stumbling block was. I’ve seen >> Tuple<Long,Long> used in public APIs in some code bases - where a typed >> class that wraps it is for more appropriate - not good, and very poor >> maintainability. >> >> >> But, people cry, boxing is SLOW, and we want Go to be FAST! This paper >>> https://research.swtch.com/generic is citied multiple times as a charge >>> against boxing. >>> >> >> Not quite. That article is cited to clarify that you need to *decide* on >> what tradeoff you want to make and to justify it. Boxing - choosing "slow >> programs" in the parlance of the article - is a reasonable choice to make, >> but you should do so deliberately and make a good case for why it's the >> right choice. >> >> It's also used as a reference to quickly explain one example of the >> current design, which is that it makes that decision no longer a language >> decision, but an implementation decision. i.e. we don't even know if >> generics in Go will be boxed or not - we can decide that later and change >> the decision at will. >> >> >> I disagree with your reading here. The statement from the article is "*do >> you want slow programmers, slow compilers and bloated binaries, or slow >> execution times?**”* >> >> and as I pointed out, Go’s method dispatch is already slower than Java in >> both the direct and interface cases. So citing Java and ‘slow execution >> times’ as a problem with generics s incorrect by the author, and that >> people keep citing it as fact is troublesome. People have proposed >> interface based generics for Go, and the criticism is most of the time - >> that will be slower... >> >> > I think you haven't seen what people need to do in Java to make it > performant. As an example: > > > https://mechanical-sympathy.blogspot.com/2012/10/compact-off-heap-structurestuples-in.html > > That example is more about value types, but also implicitly a problem with > boxing. > > The boxing overhead is most visible with having things like > ArrayList<byte>. > > Indeed there are places where Java can erase some of the performance > overhead, even more so with GraalVM. (Not sure about the memory overhead) > > >> Now the reason for this is almost certainly that Java can inline across >>> virtual function calls >>> >> >> I would say that the core advantage of Java is likely that it is >> JIT-compiled and as such can do a whole bunch of optimizations that an >> AOT-compiled language like Go can't do. But I might be wrong. >> >> I also don't think it matters a lot. I think it's more important what >> works for Go, than what worked for Java. The two languages are very >> different in both semantics and implementation. Conclusions from one don't >> necessarily transfer to the other. >> >> >> Exactly, Go is very simple, and ideal for the cases I pointed out in the >> original post (and I’ll add, micro-services too), and so far all of the >> proposals that seem to be gaining traction don’t continue that design >> paradigm. >> >> -- >> 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/d/optout. >> >> >> > -- > 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/d/optout. > > > -- 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.
