3 ms·

The speed at which a big data set is processed has nothing to do with the language or its' compiler. It's the way in which the data set is streamed through memo

by thwd 10y ago

The speed at which a big data set is processed has nothing to do with the language or its' compiler. It's the way in which the data set is streamed through memory by a particular program. Go offers two standardized interfaces for this, `io.Reader` and `io.Writer`. Also, if the data set can be batched, it's trivial to parallelize processing in Go, while it's a big hurdle in Java. A JIT is not a performance feature per-se, either. It can be used for runtime code-optimization and -specialization which can improve performance. Some JVM implementations try and do this as well as they can automatically. The stuff they optimize, though, is exactly the kind of indirection that doesn't exist in Go in the first place. The optimizations `javac` does are one of the few things that allows Java code to run at a competitive speed. And they're mostly trading space for performance, hence the unusually large memory footprint of Java applications.

kasey_junk 10y ago
The big data set stuff I generalized around has more to do with the runtimes involved. Most JVM gc systems for instance are moving collectors while the golang one isn't (or wasn't last I looked). This can cause slow downs in comparison to a comparable GC environment especially around large data sets in long running environments. "And Go allows for more control about the memory layout of structs/classes and arrays." Is an absolutely true statement, and it means that for some classes of problems (namely systems that prioritize GC latency for throughput) golang might be faster. The opposite is also true, especially with regard to large interdependent data sets, the golang runtime handles those worse than most JVMs. I'd also completely disagree with your statement "Also, if the data set can be batched, it's trivial to parallelize processing in Go, while it's a big hurdle in Java." Especially with regard to "fast". There are more & better high performance concurrency libraries in Java than there are in go. All that said, I was really reacting to this line "This is much faster than C# or Java, which compile to an intermediate interface" which is utter nonsense. In the end, talking about performance in such large grained ways is usually not valuable but I'm willing to say that golang performs in the same category of performance as most jvms and that calling go faster than java is nonsense unless you speak about very specific cases.

by thwd 10y ago

kasey_junk 10y ago

The big data set stuff I generalized around has more to do with the runtimes involved. Most JVM gc systems for instance are moving collectors while the golang one isn't (or wasn't last I looked). This can cause slow downs in comparison to a comparable GC environment especially around large data sets in long running environments. "And Go allows for more control about the memory layout of structs/classes and arrays." Is an absolutely true statement, and it means that for some classes of problems (namely systems that prioritize GC latency for throughput) golang might be faster. The opposite is also true, especially with regard to large interdependent data sets, the golang runtime handles those worse than most JVMs. I'd also completely disagree with your statement "Also, if the data set can be batched, it's trivial to parallelize processing in Go, while it's a big hurdle in Java." Especially with regard to "fast". There are more & better high performance concurrency libraries in Java than there are in go. All that said, I was really reacting to this line "This is much faster than C# or Java, which compile to an intermediate interface" which is utter nonsense. In the end, talking about performance in such large grained ways is usually not valuable but I'm willing to say that golang performs in the same category of performance as most jvms and that calling go faster than java is nonsense unless you speak about very specific cases.