8 ms·
The big issue with D, in terms of no-overhead is that is has garbage collection by default, and if I understand correctly, the garbage collector is not as advan
by RcouF1uZ4gsC 7y ago
The big issue with D, in terms of no-overhead is that is has garbage collection by default, and if I understand correctly, the garbage collector is not as advanced as Java's or Go's.
While you can use D without the garbage collector, you will lose access to a lot of the standard library, which limits the practicality of running without garbage collection.
- apta 7y ago> is not as advanced as Java's or Go's. golang's GC isn't advanced either.
- Thaxll 7y agoI'm not sure what qualified for an advanced GC but Go is the leading GC with Java and C# so ... https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote
- The_rationalist 7y agoI don't know if it's a consequence of their GC, but go is significantly slower than Java or C#.
- Thaxll 7y agoYou're mistaken, Go is on part with both languages, usually faster.
- dralley 7y agoMy understanding is that it has lower latency but also lower throughput. Although most of the benchmarks I've seen are at lease 2 years old. It would be nice to see some updated benchmarks that also compare against the Shenandoah and ZGC garbage collectors for the JVM.
- apta 7y agoJava is getting two new low latency collectors. golang is stuck with a GC that favors latency over throughput, making it not suited for high throughput processing.
- hu3 7y agoBy stuck you mean Go devs made the sensible decision to have only one, zero configuration, ultra low latency, Garbage Collector that suits Go's common use cases instead of trying to be jack of all trades having many GC's each with their pletora of knobs to adjust.
- apta 7y agoIt means that golang is relegated to simple server side tools, and not suited for a broader range of programs like the JVM is.
- hu3 7y agoYep. Go has a focus. That's how you get from zero to heavy usage in companies like Uber, Twitter, Cloudflare, BBC, Basecamp, Canonical etc... in less than a decade.
- apta 7y agoYou'd be surprised at the extent hype influences decision making when it comes to choosing which language to use (even in companies you mentioned), at a significant cost down the line. I'll just say I know people at one of the companies you mentioned, and the amount of friction and cost due to them using golang is quite remarkable.
- hu3 7y agoNo offense but I'd rather trust the engineers of all these companies combined over an anecdote on the internet. Not to mention technology change always generate friction. You just can't please everyone.
- apta 7y agoFor real world, non-trivial programs, golang lags behind Java/JVM.
- The_rationalist 7y agoWell, on the benchmarckgame (internet reference for microbenchmarks), you're mostly right, go is faster than Java but slower than c#. But real-world applications performance needs fine tuned libraries that scales and this is where Java destroy both go and c#.
- apta 7y agoTake the benchmarkgames site with a big grain of salt. They're running on an old processor, and that biases results a lot. For example, someone submitted a patch that significantly sped up a Java benchmark by using `Math.fma()`. However, because the processor the benchmarks site is running on is old and does not support the underlying instruction that `Math.fma()` uses, it ended up way slower. I ran several benchmarks locally on a CPU that's a few years old where the benchmarks site shows golang being faster than Java, without changing the code, and I got the opposite result (Java was faster). Especially the longer the program ran. For example, the site shows that golang is faster in the spectral norm benchmark. Running it locally with a larger input parameter: golang: time ./test 30000 1.274224153 18.81 real 70.19 user 0.38 sys Java: time java spectralnorm1 30000 1.274224153 16.18 real 105.95 user 0.45 sys Or with the nbody benchmark: golang: time ./nbody 60000000 -0.169075164 -0.169012474 6.09 real 6.04 user 0.02 sys Java: time java nbody 60000000 -0.169075164 -0.169012474 6.04 real 5.94 user 0.06 sys
- Thaxll 7y agoFastHTTP destroys Netty, isn't Netty a fined tuned library?
- e12e 7y agoI'm not sure - I don't use either go or Java much these days - but some cursory googling implies that light-4j/undertow core is to fasthttp as netty is to net/http? https://github.com/networknt/light-4j/ https://github.com/networknt/light-4j/
- 7y ago
- sorokod 7y agoThe page you link to does not compare Go's GC to Java's or C#'s
- littlestymaar 7y agoIf you are interested on that topic these two posts are a must read: - https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e https://blog.plan99.net/modern-garbage-collection-911ef4f8bd... - https://blog.plan99.net/modern-garbage-collection-part-2-1c88847abcfd https://blog.plan99.net/modern-garbage-collection-part-2-1c8... The main takeaway is that saying that Go is the leading GC is just a (somewhat dishonest) PR move, and Go's team made a pretty good GC given there project constraints, even of it is not at the state of the art at the moment.
- Thaxll 7y agoI never said that it was state of the art or "the" leading, my point is Go GC is currently a good all-arround GC, and I've read that article, I think the author is bias against Go and currently there is no article even proving that the 2 new Java GC are faster than the Go one. ( or even faster than G1 ) You know when you end your article with "Overall, it looks to me like the Java guys are winning the low latency game." when none of those GC are actually production ready ... Go GC low latency has been stable and used for some time now. Out of the box Go GC is very good and doesn't need all the memory or the tunning from G1. ( I spend years tunning GC for Java application it's a nightmare )
- geodel 7y agoThis is must read only for GC theory enthusiasts. Java GC is advanced and better performing but that is adjusted by Java program's heavy garbage generation. So overall gain by advanced GC is little if any in Java.
- tick_tock_tick 7y agoDepends what you mean by advanced. In many ways it's more closer to achieving it's stated goals then Java's.
- apta 7y agoJavas GCs already achieve their goals. The JVM has several GCs to select from based on the needs such as: high throughput, very large heap sizes (up to the TB range), and there are two in experimental phase for very low latencies (ZGC and Shenandoah).
- hu3 7y ago> Javas GCs already achieve their goals. So does Go. Otherwise it wouldn't be anywhere as popular specially with regards to server-side usage by giants of the industry.
- pjmlp 7y agoGoogle's stamp helps. Java GC don't need allocation tricks of several GBs, like Twich was forced to do.
- tick_tock_tick 7y agoTwitch did that since they preferred to use code over environment configuration. They could have achieved similar results using the GOGC environment variable but didn't want too; They even said so in there post.
- lightgreen 7y ago> very large heap sizes It is not heap size that matters, but how often old objects are mutated. Basically, if you have 1TB of immutable objects, you are lucky, but if you constantly modify all the heap, then you will have a lot of headache. GC authors continuously mislead on this issue for many years (they promised the same with multi gigabyte heaps but with G1 several years ago).
- WalterBright 7y agoYou can avoid using the GC by using malloc/free. You can also use -betterC and D will only need to be linked with the C standard library. > you will lose access to a lot of the standard library This is incorrect. Not much of it needs the GC anymore.
- zerr 7y agoSince D has scope guards - any plans to add deterministic destructors? i.e. RAII a la C++.
- destructionator 7y agoThey've been there... I think since the beginning. If not since the beginning for at last ten years now.
- mhh__ 7y agoAlready there. P.S. click the link to see the spec...
- qznc 7y agoStruct destructors are always deterministic: https://dlang.org/spec/struct.html#struct-destructor https://dlang.org/spec/struct.html#struct-destructor Class destructors can be declared deterministic with the "scope" keyword: https://dlang.org/spec/attribute.html#scope https://dlang.org/spec/attribute.html#scope Scope guards are useful if you cannot change the data type itself.
- wyldfire 7y agoIt's my estimation that this misperception of D (that it requires GC) will take a while to unlearn/relearn.
- pjmlp 7y agoNot only of D, plenty of GC enabled languages (including .NET based ones) provide such capabilities, but for some reason many learn wrongly that having a GC means 100% heap usage with GC only allocations.
- earenndil 7y agoYou also have a lot of control over when the GC runs. You can manually disable it and run collection cycles, and it only runs when you allocate. You can also mark a section as @nogc to ensure there's no GC usage.
- WalterBright 7y ago> is not as advanced as Java's or Go's An advanced GC requires having "write gates" inserted into the generated code. These take away from performance, but in a language like Java that makes very heavy use of the GC, the gain in GC performance outweighs the slower code. D is not a GC heavy language, even if all you use is the GC, hence it is a poor tradeoff. (For example, in D you can use the stack for a great deal of the routine allocations, whereas in Java these are often done with the GC. Java has optimizations to try and detect when allocations can be done on the stack, but this isn't as effective as proactively putting them on the stack.)
- dan-robertson 7y ago> An advanced GC requires having "write gates" inserted into the generated code This isn’t strictly true. In particular it is possible to design a GC such that write barriers are implemented in hardware (these days using the mmu not dedicated hardware). It’s also possible to write a (non-incremental non-concurrent non-parallel) gc that uses no write barriers: just stop the world, collect and move. The mmu-for-write-barrier technique I’ve seen is to keep pointer colour in high bits and map the same physical memory onto n copies of itself in virtual memory (so you don’t need to mask the colour bits away before dereferencing). When the mutator tries to write to a black pointer (or maybe pointers are coloured by whether their targets might have moved?), the gc gets a memory exception and can ensure that the invariants are maintained. The general assumption is that this doesn’t happen very often in most programs. I can’t remember the name of the system I’m thinking of but it’s one of the new GCs being developed for java. An alternative method to avoid a write barrier is avoiding mutation in your programming language. This makes GC simpler. There are other advantages and disadvantages
- WalterBright 7y agoI implemented a write gate using the MMU once. It was quite a bit slower, and I abandoned it.
- qznc 7y agoWhile the opinion-pendulum is currently on the contra-GC side, I still believe GC is the correct default. Mostly because GC is easier than manual memory management. If you have real-time needs, then GC is probably out. That includes handling audio and video playback. Tight memory constraints are another killer argument against GC but that only applies to small embedded devices. Smartphones, desktops, and servers have enough RAM. The great thing about D is that you can start the easy way with a GC. When real-time or memory become constraints at some point you can selectively adapt parts of your program. You could say, D wants to provide Python and Rust and everything in between so that you can shift seamlessly to wherever your specific sweet spot is. Different parts of your program can even use different spots. In a game engine, you could have the audio and rendering parts as non-GC real-time code, while the game logic is easy high-level script-like. We are very used to a scripting language plus compiled language combo these days but is the separation a good one?
- nickpsecurity 7y agoDon't rule real-time out. Real-time GC's exist. People just need to build open ones for these languages. Example write-up on this: http://michaelrbernste.in/2013/06/03/real-time-garbage-collection-is-real.html http://michaelrbernste.in/2013/06/03/real-time-garbage-colle...
- Const-me 7y agoIn my experience (.NET, including mobile and embedded) when handled with care, GC is often fine even for audio and video. The trick is not loading the GC too much, neither in terms of allocations/second nor bytes/second (for multimedia it means recycling buffers as opposed to creating/destroying), also having enough RAM so you don’t need to use 80% of installed memory.
- pjmlp 7y agoJust yesterday I posted a link about real time audio processing done in Java. Anti-GC hate seems to always come from religious objection or having had back luck not understanding how to actually use the tools at their disposal.
- 7y ago
- crazypython 7y agoYou can manually use free/allocation and use `scope` classes to avoid GC. Closures only use GC when you don't explicitly delete stuff.
- skocznymroczny 7y agoI'd say the opposite. I wouldn't say it's an issue, but personally I wish D didn't offer alternative memory management options. Other languages like Go or C# don't even give you a choice, so people just accept it and move on. But every discussion on D always turns into the "evil GC" discussion. I use a lot of D and was never bothered by the GC and I find it easier to work with than manual memory management. I guess I could live with automatic refcounting too but I doubt it could be integrated well into the language at this point.