Re: [go-nuts] Go without garbage collector

On 2020-03-03 22:22, Robert Engels wrote: > A key statement in the link “ The JIT-generated code is *significantly* faster > than the ahead-of-time-generated code for small matrix sizes.” > > Which is what you were arguing was not possible... you can’t have it both > ways. JIT code often

Re: [go-nuts] Go without garbage collector

implementations for certain parameters types (the classic sort() uses counting sort for small domains (char keys), and quick-sort for others (arbitrary keys)).-Original Message- From: ⚛ <0xe2.0x9a.0...@gmail.com> Sent: Mar 3, 2020 4:35 PM To: golang-nuts Subject: Re: [go-nuts] Go without g

Re: [go-nuts] Go without garbage collector

> > On Tuesday, March 3, 2020 at 11:25:22 PM UTC+1, Robert Engels wrote: > A key statement in the link “ The JIT-generated code is significantly > faster than the ahead-of-time-generated code for small matrix sizes.” > > Which is what you were arguing was not possible... you can’t have it both

Re: [go-nuts] Go without garbage collector

On Friday, February 14, 2020 at 6:57:08 PM UTC+1, ⚛ wrote: > > On Friday, February 14, 2020 at 6:46:51 PM UTC+1, Robert Engels wrote: >> >> Yes, and then the access and iteration is slower as it needs indirection >> to find the correct page. There is no free lunch. >> >> The caveats about using

Re: [go-nuts] Go without garbage collector

...@gmail.com> Sent: Feb 14, 2020 11:57 AM To: golang-nuts Subject: Re: [go-nuts] Go without garbage collector On Friday, February 14, 2020 at 6:46:51 PM UTC+1, Robert Engels wrote:Yes, and then the access and iteration is slower as it needs indirection to find the correct page. There is n

Re: [go-nuts] Go without garbage collector

On Friday, February 14, 2020 at 6:46:51 PM UTC+1, Robert Engels wrote: > > Yes, and then the access and iteration is slower as it needs indirection > to find the correct page. There is no free lunch. > > The caveats about using mutable objects, sharing, and concurrency still > apply. > > A

Re: [go-nuts] Go without garbage collector

I was using the code as a baseline to demonstrate improvements in JVM/GC technology, nothing more - and for that it was appropriate.-Original Message- From: ⚛ <0xe2.0x9a.0...@gmail.com> Sent: Feb 14, 2020 11:37 AM To: golang-nuts Subject: Re: [go-nuts] Go without garbage collector On

Re: [go-nuts] Go without garbage collector

On Friday, February 14, 2020 at 6:24:08 PM UTC+1, Robert Engels wrote: > > > Yes, and when you store value objects in a vector and it is resized, it is > very expensive as you need to make copies of "large objects", vs a "pointer > to an object". > A paged vector neither copies nor moves the

Re: [go-nuts] Go without garbage collector

Message- From: Robert Engels Sent: Feb 14, 2020 11:23 AM To: Alex Besogonov Cc: ⚛ <0xe2.0x9a.0...@gmail.com>, golang-nuts Subject: Re: [go-nuts] Go without garbage collector Yes, and when you store value objects in a vector and it is resized, it is very expensive as you need to make

Re: [go-nuts] Go without garbage collector

eb 14, 2020 11:01 AM To: Robert Engels Cc: ⚛ <0xe2.0x9a.0...@gmail.com>, golang-nuts Subject: Re: [go-nuts] Go without garbage collector No, you do not. In C++ you would put object values in the vector, rather than pointers to objects.On Feb 14, 2020, at 08:57, Robert Engels <reng...@ix.

Re: [go-nuts] Go without garbage collector

lunch. > > -Original Message- > From: ⚛ <0xe2.0x9a.0...@gmail.com <mailto:0xe2.0x9a.0...@gmail.com>> > Sent: Feb 14, 2020 8:52 AM > To: golang-nuts > Subject: Re: [go-nuts] Go without garbage collector > > On Friday, February 14, 2020 at 3:43:4

Re: [go-nuts] Go without garbage collector

a complex sparse array structure, and then you pay the performance hit during iteration). There is no free lunch.-Original Message- From: ⚛ <0xe2.0x9a.0...@gmail.com> Sent: Feb 14, 2020 8:52 AM To: golang-nuts Subject: Re: [go-nuts] Go without garbage collector On Friday, February 14,

Re: [go-nuts] Go without garbage collector

On Thu, Feb 13, 2020 at 7:48 PM Alex Besogonov wrote: > And no, reference counting is NOT a GC. > > General consensus, at least among academia, is that automated reference counting is a GC scheme. You may argue that it is not based on whether it is implicitly done (Like Ruby and Python

Re: [go-nuts] Go without garbage collector

On Friday, February 14, 2020 at 3:43:40 PM UTC+1, Robert Engels wrote: > > If each object exists independently - which it does in this case - you > must use a free on each object. So you are going to loop - it just may be > hidden from you. > I am sorry, I do not understand your style of

Re: [go-nuts] Go without garbage collector

If each object exists independently - which it does in this case - you must use a free on each object. So you are going to loop - it just may be hidden from you. The idea was to avoid all free calls and terminate the process instead - which I pointed out has been a solution for quite a long

Re: [go-nuts] Go without garbage collector

On Friday, February 14, 2020 at 3:32:54 AM UTC+1, robert engels wrote: > > You can clearly see that the vast majority of CPU time was consumed by > allocation and de-allocation. > In the case of this particular benchmark, it is pointless to be pointing out the cost of individual malloc+free

Re: [go-nuts] Go without garbage collector

as still there.-Original Message- From: Robert Engels Sent: Feb 13, 2020 2:27 PM To: ⚛ <0xe2.0x9a.0...@gmail.com>, golang-nuts Subject: Re: [go-nuts] Go without garbage collector I find it difficult to believe that"However, on a desktop CPU with 32 MB of LLC, x86-64 mode, std::un

Re: [go-nuts] Go without garbage collector

ert Engels Sent: Feb 13, 2020 11:33 AM To: ⚛ <0xe2.0...@gmail.com>, golang-nuts Subject: Re: [go-nuts] Go without garbage collector I won't dispute that, but at least this particular case, it requires on-going maintenance by the developer (company). In this case of Java very few perform

Re: [go-nuts] Go without garbage collector

On Feb 13, 2020, at 1:45 PM, Robert Engels wrote: > > Swift uses GC - it uses a reference counting GC which has been proven to be > inferior compared to tracing collectors - especially in concurrent > environments. Not to mention cycles. Worth noting, too, that Swift does this largely because

Re: [go-nuts] Go without garbage collector

he difference in our experiences. > > > -Original Message- > From: Robert Engels > Sent: Feb 13, 2020 11:33 AM > To: ⚛ <0xe2.0...@gmail.com >, golang-nuts > Subject: Re: [go-nuts] Go without garbage collector > > I won't dispute that, but at least this par

Re: [go-nuts] Go without garbage collector

To: Robert Engels Cc: golang-nuts Subject: Re: [go-nuts] Go without garbage collector Then other languages should faithfully replicate C++ code. For example, iteration in Java should be done like this:for( AtomicReference iter = arr.iterate(); iter.get().hasNext(); iter.get().next()) {...}And no,

Re: [go-nuts] Go without garbage collector

bit, and some more research would be helpful. > > -Original Message- > From: Alex Besogonov > Sent: Feb 13, 2020 12:18 PM > To: Robert Engels > Cc: golang-nuts > Subject: Re: [go-nuts] Go without garbage collector > > No. It doesn’t prove anything. The C++ code is

Re: [go-nuts] Go without garbage collector

13, 2020 12:18 PM To: Robert Engels Cc: golang-nuts Subject: Re: [go-nuts] Go without garbage collector No. It doesn’t prove anything. The C++ code is badly written, as it creates completely superfluous objects (probably optimized away) and does an indirect lookup (which will NOT be). This needs

Re: [go-nuts] Go without garbage collector

No. It doesn’t prove anything. The C++ code is badly written, as it creates completely superfluous objects (probably optimized away) and does an indirect lookup (which will NOT be). This needs to be fixed even if the code is a faithful translation of Java code. So in practice all the supposed

Re: [go-nuts] Go without garbage collector

ge- > From: ⚛ <0xe2.0...@gmail.com > > Sent: Feb 13, 2020 9:57 AM > To: golang-nuts > Subject: Re: [go-nuts] Go without garbage collector > > On Thursday, February 13, 2020 at 3:05:45 PM UTC+1, Robert Engels wrote: >> >> The code hasn’t been chang

Re: [go-nuts] Go without garbage collector

the performance to the level of Java ?This is not my experience. Did you actually do this?-Original Message- From: Robert Engels Sent: Feb 13, 2020 11:33 AM To: ⚛ <0xe2.0x9a.0...@gmail.com>, golang-nuts Subject: Re: [go-nuts] Go without garbage collector I won't dispute that, but at

Re: [go-nuts] Go without garbage collector

, IntegerList to avoid boxing...)-Original Message- From: ⚛ <0xe2.0x9a.0...@gmail.com> Sent: Feb 13, 2020 9:57 AM To: golang-nuts Subject: Re: [go-nuts] Go without garbage collector On Thursday, February 13, 2020 at 3:05:45 PM UTC+1, Robert Engels wrote:The code hasn’t been changed. The perfo

Re: [go-nuts] Go without garbage collector

On Thursday, February 13, 2020 at 3:05:45 PM UTC+1, Robert Engels wrote: > > The code hasn’t been changed. The performance numbers have changed > dramatically with no developer intervention. No “hand optimizing” required. > C++ evolves over time also. Hashmaps have been added to C++ in C++11,

Re: [go-nuts] Go without garbage collector

One other minor point on the proposed optimization, if this were a concurrent collection you wouldn’t do this (eg a ConcurrentHashMap in Java) because the end point changes. So again, more cognitive load and maintenance issues in the C++ world as you need far deeper knowledge of the systems

Re: [go-nuts] Go without garbage collector

To reiterate, this demonstrates the advancements in GC and JVM tech. These types of tests aren’t well representative of Java’s current sweet spot - which is long running server processes with Gigs of memory, but it still perform admirably - even when including startup costs and runtime memory

Re: [go-nuts] Go without garbage collector

I understand that English may not be your primary language, but please reread the first sentence again. Beyond that you still miss the point. The code hasn’t been changed. The performance numbers have changed dramatically with no developer intervention. No “hand optimizing” required. The

Re: [go-nuts] Go without garbage collector

On 2/13/20, robert engels wrote: > See this paper/project https://github.com/hundt98847/multi-language-bench > that was done by Google > in 2011. > > ... > > Or Java is almost 2x faster than C++, and Go is nearly the same performance > as C++.

Re: [go-nuts] Go without garbage collector

On Wednesday, 12 February 2020 22:57:04 UTC, robert engels wrote: > > (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). > > This is discussed in great detail here: https://blog.golang.org/ismmkeynote

Re: [go-nuts] Go without garbage collector

I actually remember another actual example of a code that does non-trivial work and is written in multiple languages: https://github.com/ixy-languages/ixy-languages It's pretty clear that C or Rust still easily beat any GC-based language. Go and C# come close because the code for the driver

Re: [go-nuts] Go without garbage collector

On Thursday, February 13, 2020 at 6:59:43 AM UTC+1, robert engels 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 > that > was done by Google in 2011. If you read the

Re: [go-nuts] Go without garbage collector

The evidence is very disputable. For example, I don't know who was writing your paper, but they were NOT expert C++ programmers. As an example: > for (MaoCFG::NodeMap::iterator bb_iter = CFG_->GetBasicBlocks()->begin(); > bb_iter != CFG_->GetBasicBlocks()->end(); ++bb_iter) { >

Re: [go-nuts] Go without garbage collector

icular 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 >> >>

Re: [go-nuts] Go without garbage collector

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

Re: [go-nuts] Go without garbage collector

; 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

Re: [go-nuts] Go without garbage collector

lding 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

Re: [go-nuts] Go without garbage collector

On Wed, Feb 12, 2020 at 2:56 PM 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

Re: [go-nuts] Go without garbage collector

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 &

Re: [go-nuts] Go without garbage collector

Honestly, typical Go programs don't use that many complicated concurrent primitives. Typical patterns are "work fanout" and "overseer thread", both of which have very simple lifetime rules. That's why a lot of typical server Go code can be ported to Rust rather easily. On Wednesday, February

Re: [go-nuts] Go without garbage collector

> On Feb 12, 2020, at 10:10 AM, Henrik Johansson wrote: > > Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times better > so that particular example isn't really helping the GC case. > > I don't mind the GC myself but I hear the "GC is actually faster" often and > it seems

Re: [go-nuts] Go without garbage collector

it back).-Original Message- From: alex.besogo...@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

Re: [go-nuts] Go without garbage collector

On Wednesday, February 12, 2020 at 12:55:48 AM UTC+1, deat...@gmail.com wrote: > > What about #vlang ? https://vlang.io/ > If compile-time GC is the only memory management model that exists in V, then it is impossible to implement in V any program requiring dynamic/runtime GC such as a Python

Re: [go-nuts] Go without garbage collector

To me it seems the issue of concurrency and dynamic ownership of memory are so deeply connected to Go’s programming methodology that the “no GC” comparison is biased. In particular, coding to do it yourself but as perfectly as the GC across many concurrent routines is hard. Doing it better than

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

Re: [go-nuts] Go without garbage collector

Absolutely but this has been said for a very long time already and we have still to see it. I agree GC's are getting better and better and who knows what the future holds. Until then I will gladly ignore the small loss of performance simply becausenit rarely matter for the program's I write. On

Re: [go-nuts] Go without garbage collector

Very well said.-Original Message- From: Jesper Louis Andersen Sent: Feb 12, 2020 12:13 PM To: Henrik Johansson Cc: Kevin Chadwick , golang-nuts Subject: Re: [go-nuts] Go without garbage collector If I may make an observation here:I think the vast majority of all programs benefit

Re: [go-nuts] Go without garbage collector

If I may make an observation here: I think the vast majority of all programs benefit in productivity from a GC. In the sense, that the GC is an adequate solution at the least, and a more efficient solution in many cases, especially if you factor in development time. Managing memory manually,

Re: [go-nuts] Go without garbage collector

Most embedded systems are highly modular with limited inputs and outputs. It is far easier to apply custom memory handling to the module. It’s is the larger controller application that is far more complex as it has to deal with all of the inputs BBC and outputs of every module. It is very hard

Re: [go-nuts] Go without garbage collector

Your paper proves your conclusions given your assumptions :) When there is no GC runtime in a language, you are open to managing memory however you see fit, and there are lots of models which are more efficient than reference counted smart pointers or whatever. I've worked on many realtime systems

Re: [go-nuts] Go without garbage collector

he GC tuning is not designed for latency with > max pauses of 500ms. > > Re-run the tests on Shenandoah or Zing and see how they compare. > > -Original Message- > From: Henrik Johansson > Sent: Feb 12, 2020 9:10 AM > To: Kevin Chadwick > Cc: golang-nuts > Su

Re: [go-nuts] Go without garbage collector

Chadwick Cc: golang-nuts Subject: Re: [go-nuts] Go without garbage collector Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times better so that particular example isn't really helping the GC case.I don't mind the GC myself but I hear the "GC is actually faster&q

Re: [go-nuts] Go without garbage collector

Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times better so that particular example isn't really helping the GC case. I don't mind the GC myself but I hear the "GC is actually faster" often and it seems not to be true in the wild although I am sure theoretical cases can be

Re: [go-nuts] Go without garbage collector

On 2020-02-12 14:02, Robert Engels wrote: > Most of that is because their codebase predates Java. There are more modern > dbs > like Cassandra that are in Java. Certainly Hadoop is probably the largest > distributed database in the world and it’s written in Java. Bound to use more cpu cycles and

Re: [go-nuts] Go without garbage collector

On 2020-02-12 13:23, Henrik Johansson wrote: > We shouldn't pretend that GC is be all end all to both developer and runtime > performance. Frankly I think performance has a lot to answer for and likely why a secure C that drops features and/or performance, has never become mainstream. A default

Re: [go-nuts] Go without garbage collector

Most of that is because their codebase predates Java. There are more modern dbs like Cassandra that are in Java. Certainly Hadoop is probably the largest distributed database in the world and it’s written in Java. > On Feb 12, 2020, at 7:24 AM, Henrik Johansson wrote: > >  > Sure, writing

Re: [go-nuts] Go without garbage collector

Sure, writing these system in a non-GC language is harder but that's not really what is talked about here right? There is a reason why databases are not really successful in Java for example. Caching software are predominantly in C/C++. Beating highly tuned C/C++ is not something that a GC can do

Re: [go-nuts] Go without garbage collector

Aren’t we all all “students” :) The conclusions you cite are from the 2005 paper. I’m sure I can find other more recent peer reviewed papers that draw the same conclusions as the “student” one. I don’t think it is necessary though. If you understand how malloc or tcmalloc and how modern GC

Re: [go-nuts] Go without garbage collector

On Tuesday, 11 February 2020 23:55:48 UTC, deat...@gmail.com wrote: > > What about #vlang ? https://vlang.io/ > > https://vlang.io/docs#memory "(Work in progress) There's no garbage collection or reference counting. V cleans everything up during compilation. If your V program compiles, it's

Re: [go-nuts] Go without garbage collector

On Wednesday, 12 February 2020 05:00:41 UTC, robert engels wrote: > > I found a more recent academic paper that proves my conclusions: > > > https://www.researchgate.net/publication/326369017_From_Manual_Memory_Management_to_Garbage_Collection > > It's a student paper. The bit that caught my eye

Re: [go-nuts] Go without garbage collector

On 2020-02-12 04:53, robert engels wrote: > You can write robust systems without dynamic memory, but it is very very > difficult - beyond the skills of most developers. Interestingly, Global variables are often frouned upon and quite rightly on computer systems (I include rpi/phones), despite

Re: [go-nuts] Go without garbage collector

I found a more recent academic paper that proves my conclusions: https://www.researchgate.net/publication/326369017_From_Manual_Memory_Management_to_Garbage_Collection I am sure you can

Re: [go-nuts] Go without garbage collector

Here is a paper from 2005 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

Re: [go-nuts] Go without garbage collector

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

Re: [go-nuts] Go without garbage collector

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,

Re: [go-nuts] Go without garbage collector

What about #vlang ? 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