By the way, see the following quote and this page https://www.bytonic.de/html/benchmarks.html <https://www.bytonic.de/html/benchmarks.html> and this quote,
" November 28, 2005. Retrieved July 18, 2009. This is a great show of 3D prowess. Things like this, as well as the Narya 2D open source engine from ThreeRings really are starting to at least show Java can serve as a first-class gaming platform. More than that, just having seen all the… *cough* horrible code in games before, having things like Java’s threading model, network and database support might really make it a BETTER platform for a lot of forthcoming games than C. When the Jake2 Java based Quake engine was released, it was just as fast at the C version and far easier to develop in. Btw, I have also published gaming software, a long, long time ago… The algorithm matters more than the platform, but it needs to match the platform. You can trust the JIT to perform better code optimization than most developers... > On Sep 12, 2018, at 8:34 AM, robert engels <reng...@ix.netcom.com> wrote: > > While I always appreciate a good presentation, a little color might be in > order to get me to watch a 1.5 hr presentation. > > I’ll disagree on ByteBuffer. The prime motivation for ByteBuffer was to > abstract the concept of a memory buffer (usually bytes). The primary reason > is that byte[] has a defined meaning in the Java system, and to do NIO with > direct memory (or have off-heap memory to avoid GC) they needed an > abstraction layer - so you could implement DirectByteBuffer. Nothing to do > with generics. Then with this specialized class, the VM can use intrinsics to > make ByteBuffer perform as well as Java memory, or native memory. > > Go doesn’t need this, since the byte[] in Go is already a native pointer. > >> On Sep 12, 2018, at 8:15 AM, Egon <egonel...@gmail.com >> <mailto:egonel...@gmail.com>> wrote: >> >> 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 >> <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 >>> <http://gmail.com/>> 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 <http://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 >>>> <http://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 >>> >>> <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 <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 >>> >>> <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 <http://googlegroups.com/>. >>>> For more options, visit https://groups.google.com/d/optout >>>> <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 <>. >>> For more options, visit https://groups.google.com/d/optout >>> <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 >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
