Curious; how close do things like Rust, now or in the near future, come to "replacing" C/C++? Are they even meant to?
The “C Is Efficient” Language Fallacy (2006)
51–60 of 106 posts
Re: The “C Is Efficient” Language Fallacy (2006)
#52That's not "C is inefficient", it's "Sequental computation is inefficient". Want a lot of "number-crunching"? Learn CUDA (or similar non-hardware-locked thing). It's quite simple to get into and you can get orders of magnitude speed boost. Screw Fortran, it's 2016!
Re: The “C Is Efficient” Language Fallacy (2006)
#53That's not "C is inefficient", it's "Sequental computation is inefficient". Want a lot of "number-crunching"? Learn CUDA (or similar non-hardware-locked thing). It's quite simple to get into and you can get orders of magnitude speed boost. Screw Fortran, it's 2016!
cough That still amounts to "C is inefficient." You just gave different evidence that makes a lot more sense in 2016 than it would have in 2006.
Re: The “C Is Efficient” Language Fallacy (2006)
#54That's not "C is inefficient", it's "Sequental computation is inefficient". Want a lot of "number-crunching"? Learn CUDA (or similar non-hardware-locked thing). It's quite simple to get into and you can get orders of magnitude speed boost. Screw Fortran, it's 2016!
cough That still amounts to "C is inefficient." You just gave different evidence that makes a lot more sense in 2016 than it would have in 2006.
The whole point is - it's not about a concrete language (CUDA-C syntax is almost the same as C, you know). It's about the way of thinking and completely different parallel algorithms like Blelloch scan.
There is no compiler for any language, which can turn an arbitrary sequental algorithm into parallel, and will never be.
Re: The “C Is Efficient” Language Fallacy (2006)
#55Against this article, we have the results from the computer language shootout: https://benchmarksgame.alioth.debian.org/u64q/performance.ph... I like this because anyone can try to prove their assertion that their language is faster!
Unfortunately that site is very questionable although still might be the best resource. The person who runs it changed the interface to make it difficult to compare languages as well as it used to, and he purposely doesn't include many implementations and languages that people send him. There is no ISPC or Julia, the C and C++ benchmarks use SIMD intrinsics specific to gcc, the benchmarks are run on core 2 processors…
It's a shame no one has stepped up to provide a better alternative! I don't see any reason why it shouldn't accept, test, and post all submissions automatically using something like a Docker container.
Re: The “C Is Efficient” Language Fallacy (2006)
#56Earlier quoted context omitted.
If I read the OP correctly the benchmark used an implementation of the Longest Common Subsequence algorithm, expected to run in O(n³) time and O(n²) space. It's a dynamic programming algorithm and so not quite trivial, but, hey, it's an algorithm. The coding is never the biggest complication with those. As a benchmark it's probably OK, but language benchmarks in general are never very useful. Like, the op essentially…
If you produced the exact same binary the language that was used to produce it would be inconsequential, no?
Hah. You're right, missed that.
But that's the point, isn't it? You can't ever compare two programs written in different languages claiming to test "the same program" written in different languages. Because in the end either they're not the same program, so there's no comparison, or they're the same program, so what are you really comparing?
Re: The “C Is Efficient” Language Fallacy (2006)
#57Earlier quoted context omitted.
If I read the OP correctly the benchmark used an implementation of the Longest Common Subsequence algorithm, expected to run in O(n³) time and O(n²) space. It's a dynamic programming algorithm and so not quite trivial, but, hey, it's an algorithm. The coding is never the biggest complication with those. As a benchmark it's probably OK, but language benchmarks in general are never very useful. Like, the op essentially…
If you produced the exact same binary the language that was used to produce it would be inconsequential, no?
Something else that struck me as wrong: the op counts the time the JVM needs to startup in the time it takes for the program to complete. That should be completely wrong, right? Otherwise we should count the time the physical machine took to boot up -and then the OS to load- in the time each benchmarked implementation took to complete. The JVM is a virtual computer, so why treat it any different than the physical one?
Re: The “C Is Efficient” Language Fallacy (2006)
#58Curious; how close do things like Rust, now or in the near future, come to "replacing" C/C++? Are they even meant to?
I don't think languages that are used as much as C and C++ are ever truly get "replaced".
But as for "being a viable choice instead", we intend for Rust to be so. The devil, of course, is in the details: for example, if you're on an obscure or proprietary platform, a C compiler may be your only choice. In the context of this article, while LLVM will autovectorize some things, direct control of SIMD hasn't made it into stable yet, and requires a nightly today. But as far as the language and its power goes, our goal is to be, yes.
Re: The “C Is Efficient” Language Fallacy (2006)
#59An underlying point to this article that is still true is that C isn't inherently fast -- you have to work together with the compiler to make sure it generates what you want. Why is this even worth pointing out? Well, in many languages communities (Common Lisp is a good example), the speed argument comes up, and it's pointed out that carefully working with the compiler (declares in all the right places and so on) mak…
Except that the default, basic, recommended style for writing in C and writing in some other language X often produces very reasonably fast code in C, and horribly slow code in X. Which was the whole reason people advanced the argument that you need to use contortions to get X to generate code that even approaches the speed of normal, uncontorted C.
Except for the little fact that in the 80's and 90's most hobby coders still managed to write better Assembly than C compilers for home computers were able to generate.
C compilers are fast in modern times, because of the amount of industry money spent in writing C optimizers since the industry adopted it.
Re: The “C Is Efficient” Language Fallacy (2006)
#60Earlier quoted context omitted.
Indeed. This post is nothing more than "I did this and look at the results" but offers nothing for us to repeat his tests. Plus yeah it is a decade old, things have changed a hell of a lot in the past decade.
>> This post is nothing more than "I did this and look at the results" but offers nothing for us to repeat his tests. That's a valid gripe to have, but it should be said that most scientific papers that report simulation or algorithm results do exactly the same . Reproducing results is totally left to whomever feels like (and has the time to) dispute the claims. Which is why you don't often see much in the way of dis…
But scientific papers aren't comparing Language X v.2.7.5 vs Language Y v. 16.9.1. They're comparing Algorithm X vs Algorithm Y, and usually also give theoretical results. Unless there is a big dramatic change in computer hardware, results comparing some algorithms using good implementations in a single well-optimized language will likely stand the test of time well.