6 ms·
>Every time there is a claim of "near C" performance from a higher level language like Java or Haskell, it becomes a sick joke when you see the details. They ha
by imanaccount247 12y ago
>Every time there is a claim of "near C" performance from a higher level language like Java or Haskell, it becomes a sick joke when you see the details. They have to do awkward backflips of syntax, use special knowledge of "smart" compilers and VM internals to get that performance, to the point that the simple expressive nature of the language is lost to strange optimizations that are version specific, and usually only stand up in micro-benchmarks.
I see this kind of statement a lot, and it simply does not hold up to even a cursory look. Where are the awkward backflips of syntax, special compiler or VM knowledge, or version specific optimizations here?
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=mandelbrot&lang=java&lang2=gcc&data=u32 http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=fasta&lang=java&lang2=gcc&data=u32 http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
Why are there so many java web frameworks/libraries/servers that offer performance close to C?
http://www.techempower.com/benchmarks/#section=data-r9 http://www.techempower.com/benchmarks/#section=data-r9
>Critically important to developer efficiency and productivity is the "build, run, debug" cycle.
This is a pretty bizarre claim. Sure, having an equally archaic and primitive process but 10 times slower is obviously worse (C++), but that doesn't mean having an archaic and primitive process is good if it is fast. I rarely ever run my code, much less debug it. Freeing myself from that horrible way of working was one of the greatest things about working in a language with a useful type system.
- applecore 12y agoWhat's horrible about running your own code?
- sliverstorm 12y agoI think he is saying in a round about way his code always works just right on the first compile, so he never even needs to run it before releasing it.
- Rapzid 12y agoI think he's saying he works on the code for long periods of time before worrying about how running it works out. Then he just tweaks the bits that are off and goes about his business.
- codygman 12y agoThat's exactly how I work with Haskell.
- semi-extrinsic 12y agoFunny, that's exactly how I work with Fortran (2008). And I have Syntastic in Vim nag me every time I save if I made a mistake that the compiler catches. A great advantage over C/C++ is that even on 30 000+ LoC projects split into many files, compiling from clean takes less than 30 seconds. "implicit none", of course.
- imanaccount247 12y agoNope, what Rapzid said. My code very rarely compiles first try, but when it does I have a strong amount of certainty that it will work. So I only have to run it a few times a day to check on the output, rather than every single time I compile it. Nobody said anything about releasing it without running it.
- deleted 12y ago[deleted]
- imanaccount247 12y agoNothing. What is horrible is being forced to run it constantly every single time you make a tiny change to see if you messed it up or not. I don't need to do that when I am using haskell, I just have my repl session autmatically :reload when I save a file and it tells me if I broke anything.
- vezzy-fnord 12y agoI rarely ever run my code, much less debug it. I'm not sure what you mean by this, because it sounds horribly wrong.
- lmm 12y agoImagine if just compiling your code told you all the things you get from running a good suite of unit tests. And you didn't even have to write the tests, just add a few annotation hints to help the automatic test generator occasionally. That's what a strongly typed language can get you, impossible as it sounds.
- sillysaurus3 12y agoYes, that sounds pretty impossible. Is there an example of this?
- wolfgke 12y agoGoogle "haskell quickcheck".
- charlieflowers 12y agoDoes quickcheck run at compile time for Haskell? (I've dabbled with Haskell, and I've read about Quickcheck in other languages besides Haskell. In those other languages, Quickcheck definitely does not "happen" at compile time ... does it for Haskell?)
- codygman 12y agoI'm pretty sure quickcheck is run when you do "cabal test", though you could make a compiler wrapping script that fails if your quickcheck tests fail.
- Verdex 12y agoI've seen this attitude a couple of times before and I think it's a perfectly valid reaction to have towards these statements because you're correct. It is impossible. However, type systems heavily steeped in type theory get around it being impossible by cheating. For example ... Consider the halting problem. It's pretty common knowledge that given a program and some input there's no general algorithm that tells you if that program halts when the programming language is turing complete. However, we know that every simply typed lambda calculus program halts if it passes the type checker, so did we defeat the halting problem? No we cheated because simply typed lambda calculus isn't turing complete. The problem with type theory is that sometimes it excludes good programs that we want to run just because we don't know how to prove that the program is good (or maybe it's even unprovable). So we try to develop new type theories that will allow us to prove more and more good programs are in fact good.
- CountSessine 12y agoSure, having an equally archaic and primitive process but 10 times slower is obviously worse (C++) Oh, for heaven's sake. You don't really think that, do you?
- zb 12y agoC++ compilation is much slower than C, and linking is off the charts slower. I don't think that's even controversial?
- cpeterso 12y agoC++ compile times are, in large part, are due to header files. The language moves all sorts of implementation details like class definitions and private variables and templates and inline functions.
- imanaccount247 12y agoYes? What is controversial about that?
- panzi 12y agoThe benchmarks you linked are interesting. Rust is #1, right before C: http://benchmarksgame.alioth.debian.org/u32/performance.php?test=mandelbrot http://benchmarksgame.alioth.debian.org/u32/performance.php?... Maybe Rust will finally be a real competitor to C.
- heinrich5991 12y agoAnd that without any use of `unsafe` in the submitted solution.
- jpgvm 12y agoThe only thing in the way of that right now is Rust stabilising. The future of Rust and systems programming is very bright indeed.
- deleted 12y ago[deleted]
- detrino 12y agoWhile Rust is indeed competitive with C here, its likely only number #1 because LLVM is generating better code than gcc for this example. I'd expect clang/C to run at least as fast.
- igouy 12y agoAnd see x64 http://benchmarksgame.alioth.debian.org/u64/performance.php?test=mandelbrot http://benchmarksgame.alioth.debian.org/u64/performance.php?...
- yongjik 12y ago> They have to do awkward backflips of syntax, use special knowledge of "smart" compilers and VM internals to get that performance, to the point that the simple expressive nature of the language is lost to strange optimizations that are version specific, and usually only stand up in micro-benchmarks. ...Huh, and the author thinks C doesn't? :) (Well, except the VM part.) "What Every C Programmer Should Know About Undefined Behavior" springs to mind: I believe it's been discussed several times in HN.
- coldtea 12y ago>Where are the awkward backflips of syntax, special compiler or VM knowledge, or version specific optimizations here? And then you follow with 2 links that are nowhere near idiomatic Java. Plus they are microbenchmarks (which he also mentions).
- imanaccount247 12y agoYou managed to respond, but didn't manage to actually say anything. If you want to argue the point, then make your argument. Claiming it is "nowhere near idiomatic" despite it being perfectly normal code and doing none of the things he claimed is not an argument. >Plus they are microbenchmarks (which he also mentions). Notice how I linked to the web benchmarks too? Your complaint was addressed in the post you are complaining about.
- coldtea 12y ago>You managed to respond, but didn't manage to actually say anything. If you want to argue the point, then make your argument. Claiming it is "nowhere near idiomatic" despite it being perfectly normal code and doing none of the things he claimed is not an argument. Perfectly normal code that treats Java like C. >Notice how I linked to the web benchmarks too? This does not negate the fact that you also linked to these microbenchmarks, which was what I addressed. Plus, the web benchmarks you linked to are also microbenchmarks. They are not measurements of a real life application -- it's mostly getting the framework to print "Hello World", or to do a few database calls, etc.
- deleted 12y ago[deleted]
- imanaccount247 12y ago>Perfectly normal code that treats Java like C. Again, put forth an argument. If all you can do is make unsubstantiated claims, then you might as well just keep them to yourself. You aren't furthering a discussion. >This does not negate the fact that you also linked to these microbenchmarks No, it negates your fallacious point. The claim that it only applies to microbenchmarks. The web benchmarks are not microbenchmarks, therefore it clearly does not only apply to microbenchmarks. Are you being deliberately dishonest? >Plus, the web benchmarks you linked to are also microbenchmarks If you consider an entire web server and framework to be a microbenchmark, then you are clearly being intellectually dishonest. This is not the forum for that kind of garbage, take it to reddit.
- topviz 12y agoHaskell is beautiful and mind-bending, but to get close to C in any non-trivial problem, you will end up writing imperative code. We have 4 implementations of a graph algorithm: a) Idiomatic Haskell takes ~25 minutes b) Monadic Haskell takes 11 seconds c) C++ takes 3 seconds d) C takes 1 seconds (5x less memory than b)) If you look at all the micro-benchmarks, C uses far less memory than Java or Haskell and the memory is the bottleneck in the most cases. This is the reason why HPC is FORTRAN, C and C++. Reference: Computational Topology via Functional Programming: A Baseline Analysis
- codygman 12y ago2 Things. 1. I don't think Monadic == Imperative... 2. Can you post the Haskell code?
- imanaccount247 12y ago>but to get close to C in any non-trivial problem, you will end up writing imperative code. I know that's not true because I do it on a regular basis. For problems that require writing imperative code you end up writing imperative code. This is not a problem, writing imperative code in haskell is far nice than writing it in C. >Monadic Haskell takes 11 seconds "Monadic Haskell" is meaningless when making performance claims. If you want help fixing your code, you need to post it. And idiomatic haskell uses monads all the time. Is this another case of the common "I am pretending that deliberately doing things the slowest way possible is the definition of idiomatic" trolling? >C takes 1 seconds If your C++ is taking 3x as long as your C you are doing something wrong.
- topviz 12y agoCan you give an example of the code you write which is on par with C in terms of speed and is non-trivial? Did you look up the algorithm? (it is perfectly defined recursively) Arguing what is nicer is subjective. To clarify, I did not write the code (mine is the C version), the results are from the paper. Read it, beat it and post results.
- 12y ago
- pjmlp 12y agoWhen people compare C with other languages, what they are actually comparing are optimizing implementations of native code compilers for C with 30 years of effort against implementations of other languages. Not always choosing the best ones. Specially the fact that C is fast because of 30 years of compiler research, tends to the ignored by C zealots. Lets not forget that 30 years ago C compilers used to suck really bad, and most of us that were coding back then were using Assembly for real men work. C, Pascal dialects, Modula-2, Algol dialects, PL/I and many other candidates to systems programming were all equally bad in code quality. But of course, C guys like that new generations think that C was the first systems programming language and its compilers always produced fast code.
- marktangotango 12y agoÀnd assembler was once an innovation as well. I read a quote by Richard Hamming once, he stated "automatic programming" as it was called, would be a great productivety booster.