Programming Languages And Speed

There has been tons of discussions on the subject scattered all over the place.

Now is the time to have a serious look at this issue and to draw serious conclusions once and for all.

Some experts here know very well which parts of a wiki they won't program in C/C++.

But some of us don't get it. Can someone explain what parts of a wiki they would recommended to write in C and what other parts they would not recommend to write in C?

I'm the guy that wrote the explanation of why CeeLanguage is fast, but I agree with the recent point someone made that you haven't given any reasons for why any part of this should be in C or C++. "Fast" is relative. Recent computers, even ones 5 years old, are so fast that they make basically all languages fast compared with earlier standards.

It's not like you can interact with a wiki and say, "oh, gee, this is slow, it must have been written in Perl", not at all. Usually if a web site is slow, it turns out to be for reasons other than the implementation language.

So I'm concerned that you're pouncing on the notion of using C when actually some other language would be more appropriate. Scripting languages tend to save a ton of development time. If it turns out that some piece of the final result is just too slow, then it could be optimized, either by rewriting just that component in C, or more likely, just by using a faster algorithm. That is the standard industry approach. As DonKnuth, god of algorithms, said, "Premature optimization is the root of all evil." -- DougMerritt RulesOfOptimization.

See AlternateHardAndSoftLayers

I can't think of any reason why a Wiki running on any full-fledged OS/hardware (ie not on some esoteric embedded/compact platform) would ever need to be even part-implemented in C.

What made C 's reputation as a fast language

Hmm? I already described this over on CeeLanguage. If you want a one-sentence summary, it's that C is a systems programming language that is an alternative to assembly, and as such, is designed to be compilable to extremely fast machine code. I can't think of another widely known language that also fits that description. C is unique. And, although I didn't say this before, it doesn't hurt that most cpu architectures have been designed primarily to run C fast for about two decades now; C is arguably the reason that things like the 36-bit word DEC 10/20 line died. C could not be implemented well on such machines.

[So it has to do with the fact that it needs to have less code to perform a function?]

No...let's just say that C was designed to be essentially as fast as possible, and that that is not true of any other language, so of course C is the fastest language.

And I have added the additional point that computers are now designed to run C in particular fast, so of course C runs fast on computers designed to run C fast.

(This is boiled down to the point where it is now subject to nitpicking, but it's not outright false.)

[All things being equal I am pretty sure the fastest C appication nowadays would still run on Dos]

This is a tangential issue; many C programs now require megabytes of RAM in which to run simply because megabytes are universally available (outside of embedded programming). Many Perl programs are really tiny, even just one line of code. But the Perl interpreter is too big to run under DOS. But the earliest Perl interpreters did, I believe, run under DOS. That is, Perl originated under Unix but I think it was ported to DOS way back when.

This all just confuses the issue here. There is some relationship between size and speed, but it is not a direct trivial relationship, it's a complicated it-depends relationship.

Most (computable) tasks require a space/time tradeoff. Different algorithms for the same task expend computation time in order to have smaller space requirements, or use data structures to reduce computation time. An important aspect of computer programming is understanding the consequences of space/time tradeoffs and being able to select algorithms to fit within the space and time constraints of the system.

That's certainly true, but I'm not sure how you intend that to fit into the above discussion of trying to explain why C tends to be a fast language; your comments apply to programming in any language.

C is fast because it's only one step above AssemblyLanguage in abstraction, CeePlusPlus is a step above CeeLanguage, and most other languages are a step above C++ in abstraction. Every layer of abstraction makes programming easier, but slower. Computers however, are fast enough now to make most speed issues moot. You should use the highest level of abstraction you can get away with, as it drastically reduced the necessary amount of code.

Computers however, are fast enough now to make most speed issues moot.

In some domains, for some problems, speed issues are moot. There are still entire classes of problems that can't be solved with the fastest computers running the fastest possible code.

Agreed, but most people aren't writing that kind of code, that's why I said most.

No one is writing that kind of code. The speed issues are there regardless.

...all right, here's a real-world example of speed being important and unimportant. I'm writing a computer game that has a lot of real-time calculations. AI, large-scale simulation, collision detection of all sorts of things, complexity the graphics card doesn't do for me. I'm writing it in OCaml, because OCaml is blazingly fast. If OCaml didn't exist, I would HAVE TO write it in C or something comparable to do the kind of things I want, how I want. A scripting language would not be fast enough, most lisps would not be fast enough, and I'd be pretty leery of using Java, Dylan or Erlang on it. They simply cannot do the raw computation as fast as I want them to.

I'm writing a much different computer game, a turn-based strategy game where the most CPU-intensive thing is some rather modest AI and pathfinding. If it takes a couple of seconds per turn to do this stuff, that's just fine. I'm writing it in Python, since the speed doesn't matter. If writing it in OCaml was as easy as doing it in Python, I'd do it in OCaml, but that's not the case. So I use a slow language, and it doesn't matter.

These are both very similar tasks. The code for my fast-paced, complicated action game looks quite a lot like the code for my turn-based strategy game. They have very similar architecture. They do very similar things. They use half the same libraries and algorithms. Speed is crucial in one, and not in the other.

Contributors: DougMerritt, StevenNewton