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

I understand how Zing works quite well, thank you. And no, it's still horrible. "Longer pauses in malloc" are fairy tales for children. No real allocator these days (including the slow glibc allocator) gets "fragmented". On Wednesday, February 12, 2020 at 8:18:34 PM UTC-8, robert engels wrote:

Re: [go-nuts] Go without garbage collector

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 wrote: > > Here is some pretty indisputable evidence on the advancements of GC/JVM vs > C++. > > See this paper/project

Re: [go-nuts] Go without garbage collector

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 paper, the C++ code was tuned by expert

Re: [go-nuts] Go without garbage collector

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,

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

[go-nuts] Looking for some nicely broken image files (gif, png, and jpeg)

Specifically ones that are compatible with the Go license. The more broken they are the better. Bonus points for ones that trigger degenerate behaviour in the decoding libraries. The tldr here is that I'm making a bunch of changes to the basic image libraries to add in metadata support. Since

Re: [go-nuts] Go without garbage collector

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

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

[go-nuts] Go 1.13.8 and Go 1.12.17 are released

Hello gophers, We have just released Go versions 1.13.8 and 1.12.17, minor point releases. These releases include fixes to the runtime, the crypto/x509, and net/http packages View the release notes for more information: https://golang.org/doc/devel/release.html#go1.13.minor You can

Re: [go-nuts] Go without garbage collector

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

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 in

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

It's beside the point and you are wrong but please rerun in any setup you want. Anyway for "day job" I am fine with GC. On Wed, 12 Feb 2020, 18:05 Robert Engels, wrote: > Note sure where you are getting that - their own report >

Re: [go-nuts] Go without garbage collector

Note sure where you are getting that - their own report  https://www.scylladb.com/product/benchmarks/aws-i3-metal-benchmark/ is garbage as their rational is completely flawed in choosing less bare metal nodes (but far bigger) - they have exponentially reduced the communication costs...

Re: [go-nuts] Re: Checking if two map variables refer to the same map

The playground is your friend: https://play.golang.org/p/p10XugRD4_z So, the answer is no. On Tuesday, February 11, 2020 at 6:56:05 PM UTC-5, Kevin Regan wrote: > > Would something like this work: > > m1 := make(map[string]string) > m2 := m1 > > if == { >... > } > > > On Tue, Feb 11, 2020

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] Virus detection issues on Windows/386 binaries built with -ldflags -s -w

On Tue, Feb 11, 2020 at 9:06 PM ajstarks wrote: > > VT detected issues. As mentioned these are false positives: > > https://www.virustotal.com/gui/file/77cbc92defdabf7e308849f0dd5e784010d9b4548b99b50df52533b949a14d85/detection FYI: https://golang.org/doc/faq#virus Ian > On Tuesday, February

Re: [go-nuts] Compilation of CGO project

On Wed, Feb 12, 2020 at 12:44 AM Nitish Saboo wrote: > > I have A CGO project.While compiling the project I am getting the following > error: > > In file included from > lib/../deps/syslog/syslog-ng-3.25.1/lib/logmsg/logmsg.h:31:0, > [07:38:51][shellscript] from

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

[go-nuts] Re: arm64 builder on raspberry pi 3B/3B+

The archlinuxarm.org project has great support for a variety of arm64 boards. On Tuesday, February 11, 2020 at 7:33:04 PM UTC-8, kortschak wrote: > > I have been wanting an arm64 builder to do local testing for Gonum > recently. Unfortunately, though RPi 3 and 4 have 64 bit cores, Raspbian >

[go-nuts] Compilation of CGO project

Hi , I have A CGO project.While compiling the project I am getting the following error: In file included from lib/../deps/syslog/syslog-ng-3.25.1/lib/logmsg/logmsg.h:31:0, [07:38:51][shellscript] from lib/syslog-node.c:9: [07:38:51][shellscript]

Re: [go-nuts] Re: arm64 builder on raspberry pi 3B/3B+

The builder is for running tests on GOARCH=arm64. I have previously run tests using qemu-arm, but this is currently broken (and is slow even when not broken). On Wed, 2020-02-12 at 00:15 -0800, Brian Candler wrote: > Interesting to know. > > When you say "an arm64 builder", I presume you already

[go-nuts] Re: arm64 builder on raspberry pi 3B/3B+

Interesting to know. When you say "an arm64 builder", I presume you already know that go can cross-compile any architecture on any machine (using GOOS/GOARCH). For testing,