News for hackers. Stuff that matters.
Re:Crystal: Fast as C, Slick as Ruby by paulddraper on Thursday August 04, 2016 @09:38AM (#12225381)
GCs are complex and require lots of end-user tuning -- just look at the performance articles on Java.

Beyond that, however, there are many uses for ownership beyond controlling memory resources. Closing a TCP connection, releasing a OpenGL texture...there are lots of applications of having life cycles built in to the code rather than the runtime.

EDIT: fixed typo

Re:Crystal: Fast as C, Slick as Ruby by ynniv on Thursday August 04, 2016 @09:59AM (#12225511)
just look at hand the performance articles on Java.

Just look at the hand performance articles on C... People talk about it because you can do it, not because you have to do it.

Re:Crystal: Fast as C, Slick as Ruby by paulddraper on Thursday August 04, 2016 @10:06AM (#12225567)
And you can do it because someone found that it was necessary to do.

It's crazy I can't tell Java and NodeJS "use the memory you need". Instead I have to specify max memory sizes (and then watch as they inevitably consume all of it).

Re:Crystal: Fast as C, Slick as Ruby by wtetzner on Thursday August 04, 2016 @12:54PM (#12226862)
Of course they will consume all of it. That's how GCs typically work. They won't invoke a collection until there's no space left to allocate. Just because they "use all of it" doesn't mean all of that memory is actually live. It just hasn't done a collection yet.
Re:Crystal: Fast as C, Slick as Ruby by paulddraper on Thursday August 04, 2016 @01:39PM (#12227191)
> Of course they will consume all of it. That's how GCs typically work.

Perfect agreement.

Re:Crystal: Fast as C, Slick as Ruby by oldmanjay on Thursday August 04, 2016 @01:42PM (#12227210)
The disagreement probably lies in your characterization of the GC behavior as "crazy" when it merely doesn't suit your tastes.
Re:Crystal: Fast as C, Slick as Ruby by renox on Thursday August 04, 2016 @11:02AM (#12225940)
> It's crazy I can't tell Java and NodeJS "use the memory you need".

Define the 'memory you need'? You know the computer doesn't have a cristal ball to know what latency vs memory usage trade off you want..

Re:Crystal: Fast as C, Slick as Ruby by aianus on Thursday August 04, 2016 @11:25AM (#12226125)
"Until the OS refuses to give you more"

Just like every compiled, non-GC program gets. It's annoying af to fiddle with interpreter/VM "maximum heap sizes".

Re:Crystal: Fast as C, Slick as Ruby by munificent on Thursday August 04, 2016 @12:19PM (#12226569)
Alas, "until the OS refuses to give you more" is also not a meaningful signal anymore.

https://en.wikipedia.org/wiki/Memory_overcommitment

Re:Crystal: Fast as C, Slick as Ruby by dikaiosune on Thursday August 04, 2016 @12:29PM (#12226653)
Tracing garbage collectors have to have some metric for when to trigger a stop-the-world collection. IIRC, many GCs track heap usage and trigger stop-the-world when it gets above a threshold. GC'd language runtimes which don't have a tracing/compacting collector (e.g. CPython with refcounting) don't need to configure a heap size because the behavior doesn't vary as you use up your heap.
Re:Crystal: Fast as C, Slick as Ruby by aianus on Thursday August 04, 2016 @01:29PM (#12227116)
That's still no good reason to throw all kinds of "Out Of Memory" errors when you're hitting 1GB out of the 16GB of physical memory on my system.
Re:Crystal: Fast as C, Slick as Ruby by mike_hearn on Friday August 05, 2016 @08:57AM (#12231903)
That's what most GCs do set the default max heap size to, assuming you don't have a swap file.
Re:Crystal: Fast as C, Slick as Ruby by happyslobro on Thursday August 04, 2016 @12:58PM (#12226899)
I wonder, could we just tell each JVM instance that it may use all of the memory on the system, and then let the OS kill the first VM that allocates more than the system has to offer? Would this get us the same semantics as those of a native application? Or does the JVM preallocate all of the memory that it is allowed to use?
Re:Crystal: Fast as C, Slick as Ruby by mcosta on Thursday August 04, 2016 @04:11PM (#12228113)
The JVM allocates at start a portion, takes what it needs whenever it needs until the max, but never releases memory back to the OS. So in a given moment a 6GB vm is a 5GB process but internally is using just 3GB.
Re:Crystal: Fast as C, Slick as Ruby by jerven on Monday August 08, 2016 @02:30AM (#12245802)
The standard JVMs do give memory back. The standard settings are not very friendly to do so but it does work.
Re:Crystal: Fast as C, Slick as Ruby by mike_hearn on Friday August 05, 2016 @08:52AM (#12231861)
As of one of the most recent Java releases, I believe the G1 GC does this on Windows. G1 is not the default but can be selected with a single command line flag.
Re:Crystal: Fast as C, Slick as Ruby by mcosta on Thursday August 04, 2016 @04:18PM (#12228151)
A native application on what OS?
Re:Crystal: Fast as C, Slick as Ruby by yoklov on Thursday August 04, 2016 @11:22AM (#12226103)
Most of the articles I see on C performance tuning are generalizable to any programming language, GC or no. Stuff like maintaining cache coherency, avoiding false sharing for threaded code, etc.

I don't write java, but my impression is the articles being talked about are much more java specific than the C ones are (C specific).

Re:Crystal: Fast as C, Slick as Ruby by Narishma on Thursday August 04, 2016 @04:26PM (#12228200)
Cache locality, not coherency.
Re:Crystal: Fast as C, Slick as Ruby by vosper on Thursday August 04, 2016 @10:11AM (#12225601)
Sometimes GCs require a lot of tuning, but I'd bet that 90% of software written in GC'd languages works just fine, without touching the GC settings.

In my limited experience writing performance-critical Python code the improvements always came from choosing better libraries (eg for faster serializations) or improving our own code. The GC never showed up in profiling as an issue for us.

Re:Crystal: Fast as C, Slick as Ruby by mike_hearn on Friday August 05, 2016 @08:58AM (#12231906)
Python is so slow its pseudo-GC is never the bottleneck anyway.
Re:Crystal: Fast as C, Slick as Ruby by chrislgrigg on Thursday August 04, 2016 @10:18AM (#12225658)
This is all true for some languages but I think it it's far from universal. It seems to me that in many of the most frequently used and taught modern languages, the nearest most devs will come to being concerned with GC is an awareness of why object allocation should be minimized. For their purposes, that is a much better use of time than giving any consideration to GC tuning.
Re:Crystal: Fast as C, Slick as Ruby by _ak on Thursday August 04, 2016 @01:24PM (#12227084)
Go's GC has a single setting that can be tuned: https://golang.org/pkg/runtime/debug/#SetGCPercent

And yet, it performs great, including predictable STW latencies, all with a relatively simple and straightforward algorithm. With that in mind, the Java GC's manifold ways of tuning the GC in all its aspects for minimal performance improvements sound more like something that was purposely built as something people can build their livelihood upon by providing consulting services, rather than something that was built for the best performance possible for everyone.

Re:Crystal: Fast as C, Slick as Ruby by pmelendez on Thursday August 04, 2016 @11:46AM (#12226309)
"GCs are complex and require lots of end-user tuning --"

And they tend to be very memory hungry. Often, the memory overhead is the difference between running a program or having a bunch of browser's tabs open.

Re:Crystal: Fast as C, Slick as Ruby by RX14 on Thursday August 04, 2016 @11:55AM (#12226389)
The GCs used in go or crystal tend not to eat memory more than 10% more than the peak memory of a c implementation. The perception of GC == hundreds of MBs of memory usage comes from java, where the GC aggressively preallocates, and has the memory baggage of a whole vm too. I rarely see crystal or go programs use excesses of memory.
Re:Crystal: Fast as C, Slick as Ruby by pmelendez on Thursday August 04, 2016 @12:15PM (#12226535)
I can't talk about Crystal and Go because the lack of experience with them. But the described issue is not only for Java (i.e I have seen it in Node too).

Since memory deallocation is not deterministic, there have to be a tradeoff between lazy scheduling (which increase memory consumption) or frequent scheduling (which has a performance overhead).

You can do a fine tuning between those variables but that means that a high performant with a low memory footprint system is a very challenging thing to make using a tracing garbage collection (the ones in Java and Node).

Re:Crystal: Fast as C, Slick as Ruby by lobster_johnson on Thursday August 04, 2016 @01:30PM (#12227131)
Java needs a sophisticated GC particularly because its OO model requires that it allocate an extraordinary amount of small objects, especially as things are boxed and unboxed. Ruby, one of the few true "everything is an object" languages, also suffers from an explosion of tiny objects. Node.js/V8 seems to suffer from this to a lesser extent, although it also ends up being a very memory-hungry language.

Go has been able to perform well with a simple GC because it doesn't suffer from this problem.

Re:Crystal: Fast as C, Slick as Ruby by user5994461 on Thursday August 04, 2016 @01:13PM (#12227016)
"GCs are complex and require lots of end-user tuning -- just look at the performance articles on Java."

These articles are bullshit. Most settings are either obsolete or forcing the default. The rest is just useless.

I spent months doing performance tuning of applications stacks which were using Java (for app, database or both). Most of the settings are useless and barely change +-1% in performance.

The JVM has had good defaults for a while. The only thing one MUST configure is the -Xmn and -Xmx options to set the maximum amount of memory allocated to the java process (both settings to the same value).