91–100 of 127 posts
Much as I take his overall point - that a close to the metal language is not always best for performance - the author would be well advised to take a look at the C99 restrict keyword.
Just looked it up... looks like you're right. The whole blog post is nonsense.
I use msvc mostly and gcc sometimes.
Earlier quoted context omitted.
Just looked it up... looks like you're right. The whole blog post is nonsense.
Just asking, does currently available compilers support restrict? (or C99 standards)? I use msvc mostly and gcc sometimes.
GCC's C99 implementation is mostly complete - you can find out more here: http://gcc.gnu.org/c99status.html
Always remember that the total time between you having a problem, and you achieving results, includes the coding (and recoding) time, and the run time. There's a tendency for people to ignore "slow" languages because they focus only on the runtime. I am well aware that there are good reasons to optimize things in languages like C (and I use them), but consider... If I take several extra weeks to code, debug and test…
Also, thought I would mention the fact that if you take a day to write a slow program that takes a week to run, that's cheaper than spending a week writing a fast program that finishes in a day. After all, your time is much more expensive than the computer's!
Users' time is also much more expensive than the computer's. That's why we write software in the first place.
Earlier quoted context omitted.
Another classic HLL vs. C argument: the anecdotal slow C program. Clearly, of these, there are many great examples. Unfortunately, it's a crappy argument, because there are also a zillion incredibly slow HLL programs.
That is a false dilemma tho'. No-one in the Python world has anything invested in a 100% Python solution to anything. Doing the compute-intensive bits in C is in fact expected and encouraged! The same is true in the Tcl camp. Maybe some HLL communities (Java?) like to be "pure" but I've not ever encountered that.
Earlier quoted context omitted.
Another classic HLL vs. C argument: the anecdotal slow C program. Clearly, of these, there are many great examples. Unfortunately, it's a crappy argument, because there are also a zillion incredibly slow HLL programs.
That is a false dilemma tho'. No-one in the Python world has anything invested in a 100% Python solution to anything. Doing the compute-intensive bits in C is in fact expected and encouraged! The same is true in the Tcl camp. Maybe some HLL communities (Java?) like to be "pure" but I've not ever encountered that.
Earlier quoted context omitted.
Right. C is a power tool. You can use it to create something blindingly fast. You can also use it to create something dog slow. I've seen Smalltalk programs outperform C programs. I know of an instance where a coworker benchmarked a C implementation of a block cipher vs. a Smalltalk implementation, and the Smalltalk ran 3% faster. Why? Naive manual memory management in the C implementation.
I'd like to see the c code to support this, it's very hard to imagine anything you could do this wrong in something like a block cipher that would ever make it as slow as smalltalk. I'm sorry, I just don't buy this...
So long as you keep an entire algorithm in one method, and restrict yourself to certain optimized operations, the resulting JIT-ed code will look like it was produced by an unoptimized C compiler. There will be no Smalltalk message sends. (This approach is a bit fragile, though, since you have to have esoteric knowledge to maintain code like that and keep the same level of optimization. Most of the time, you'd just implement a speed-critical operation like this as a DLL in C to be called from Smalltalk. Smalltalk/X has a different approach -- you just inline C code in your Smalltalk method.)
Combine that with naive memory management in the C code, and you have C code that loses a benchmark. Mind you, that was bad C code -- reference code only has to be correct, not fast.
"Smalltalk is Slow" usually a sign of ignorance or trolling. For lots of problem domains, the advanced commercial Smalltalk VMs are pretty darn fast.
Earlier quoted context omitted.
I have a friend at Intel who works on their realtime raytracing efforts and he swears by C/C++. Indeed, his arguments mirrors yours and go even farther. There's all sorts of magic you can play when you've got access to the actual bits and bytes. For starters, they do things like stash data in the low-precision bits of floats and the lower three bits of pointers. I wholeheartedly concur with his opinion that in raw pe…
"Premature optimization" is another hoary old argument that gets dragged into this debate every time it comes up. But I don't think it's valid. C programs start up faster than HLL programs. They run faster. They consume less memory. They tend to be more responsive. From "looking up an object by its string name" to "splitting a string on the comma character" to "running the following functions on a 10hz timer", simple…