Hacker News Reader

Comment by procaryote | Hacker News Reader

> Python, Java, C# [...] are slow

These might all be slower than well written C or rust, but they're not nearly the same magnitude of slow. Java is often within a magnitude of C/C++ in practice, and threading is less of a pain. Python can easily be 100x slower, and until very recently, threading wasn't even an option for more CPU due to the GIL so you needed extra complexity to deal with that

There's also Golang, which is in the same ballpark as java and c

View on HN

You are right, languages with tracing GC are fast. Often, they are faster than C or Rust, if you measure peak performance of a micro-benchmark that does a lot of memory management. But that is only true if you just measure the speed of the main thread :-) Tracing garbage collection does most of the work in separate threads, and so is often not visible in benchmarks. Memory usage is also not easily visible, but languages with tracing GC need about twice the amount of memory than eg. C or Rust. (When using an area allocator in C, you can get faster, at the cost of memory usage.)

Yes, Python is specially slow, but I think it's probably more because it's dynamically typed, and not not compiled. I found PyPy is quite fast.

I've built high load services in Java. GC can be an issue if it gets bad enough to have to pause, but it's in no way a big performance drain regularly.

pypy is fast compared to plain python, but it's not remotely in the same ballpark as C, Java, Golang

Sure, it's not a big performance drain. For the vast majority of software, it is fine. Usually, the ability to write programs more quickly in eg. Java (not having to care about memory management) outweighs the possible gain of Rust that can reduce memory usage, and total energy usage (because no background thread are needed for GC). I also write most software in Java. Right now, the ergonomics of languages that don't require tracing GC is just too high. But I don't think this is a law of nature; it's just that there a now better languages yet that don't require a tracing GC. The closest is probably Swift, from a memory / energy usage perspective, but it has other issues.

> and total energy usage

Surprisingly, Java is right behind manual memory managed languages in terms of energy use, due to its GC being so efficient. It turns out that if your GC can "sprint very fast", you can postpone running it till the last second, and memory drains the same amount no matter what kind of garbage it holds. Also, just "booking" that this region is now garbage without doing any work is also cheaper than calling potentially a chain of destructors or incrementing/decrementing counters.

> not visible in benchmarks

fwiw benchmarksgame uses benchexec

https://github.com/sosy-lab/benchexec

Of these languages, C# may actually be the fastest.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

In most cases the later entries in a language for the benchmark game are increasingly hyper-optimized and non-idiomatic for that language, which is exactly where C# will say "Here's some dangerous features, be careful" and the other languages are likely to suggest you use a bare metal language instead.

Presumably the benchmark game doesn't allow "I wrote this code in C" as a Python submission, but it would allow unsafe C# tricks ?

Note: 'possible hand-written vector instructions or "unsafe" or naked ffi' are flagged by *

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Note: Here are naive un-optimised single-thread programs transliterated line-by-line literal style into different programming languages from the same original.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Unsafe C# is still C# though. Also C# has a lot more control over memory than Java for example, so you don't actually need to use unsafe to be fast. Or are you trying to say that C# is only fast when using unsafe?

Likely just that the fastest implementations in the benchmarks game are using those features and so aren't really a good reflection of the language as it is normally used. This is a problem for any language on the list, really; the fastest implementations are probably not going to reflect idiomatic coding practices.

Here are naive un-optimised single-thread programs transliterated line-by-line literal style into different programming languages from the same original.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Reply on news.ycombinator.com