You''re right, but since most C compilers usually produce fast code, people say that C is fast.

- Muzzafarath

Mad House Software
The Field Marshals

In a way, yes.

But C allows a lot of language constructions that are very close to lower level languages or even the way the processor does it. This means that the programmer himself can already produce faster code then most other same or higher level languages. Just by using intelligence, which is something compilers don''t have. (not yet, ).

So looking from a higher perspective you are right that eventually every program written in any language should result in the same processor opcodes.

But compilers aren''t that smart yet so humans have to help a bit and we need lower level lanugages to help them out.

Jaap Suter

____________________________
Mmmm, I''ll have to think of one.

C code doesn''t necessarily have to be fast. I''ve written some games in DirectX using C and C++. Both programs ran at the same speed. It could be due to MSVC''s way of compiling, I don''t know. Maybe it''s because I didn''t use many C++ features (such as RTTI, operator overloading,etc). So now I''m sticking to C++ whenever possible.(Accessing COM thru C++ is less of a pain)

Also, I think that the speed of the program really depends on the programmer. If say a programmer implements a really inefficient loop in C, and another programmer makes that loop efficient in VB, that program written in VB is going to be faster.



========================================================
If something sounds stupid but works, it's not stupid

C produces faster code than pascal.
Pascal has lexical scope, C does not
Lexical scope means you can have functions defined inside of functions (parent functions variables are ''global'' to the child functions)

That means more stuff goes on the stack at each function call with pascal than C.

Polymorphism and/or virtual functions are slow operations in C++ because they require late binding of the function call. i.e. Which function gets called at some line is not known or determined until run-time. If you avoid those constructs, C++ code is not noticable slower than C code. (There may be a few more constructs that are slower, but the ones I listed will destroy performance.) Don''t ever use a base class pointer to derived class in a speed critical portion of code.

Use templates, not someother polymorphism construct.

Overloading is ok, because it binds at compile time. It makes compile time longer, not run-time

I hated that class too(Comparative Programming Languages), never thought I''d use any information from it... except that function call stack difference between c & pascal

quote:Original post by Magmai Kai Holmlor

Polymorphism and/or virtual functions are slow operations in C++ because they require late binding of the function call. i.e. Which function gets called at some line is not known or determined until run-time. If you avoid those constructs, C++ code is not noticable slower than C code. (There may be a few more constructs that are slower, but the ones I listed will destroy performance.) Don''t ever use a base class pointer to derived class in a speed critical portion of code.

This is not necessarily true at all. You could check my article on optimising C++ ( right here. ) or read "efficient C++", a book on optimising for C++. A single *this pointer dereference might be only a very small percentage of your code, even if it is on your critical path.



Give me one more medicated peaceful moment..
~ (V)^|) |<é!t|-| ~
ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full version. All important functions will be disabled from now on.

From my knowledge (so I may be in error), the answer is both in a chicken and the egg way. In the beginning, compilers weren''t that hot, requiring the programmer to hand optimize, and maybe use a bit of asm. So it was C with asm for the really fast bits. Of course asm is the fastest of all, but C''s abstraction makes it easier to use, but then compilers weren''t as good. Now, compilers are a lot better. You may not see it with a small project but they are good enough now to forgo any use of asm due to optimisation and the help of things like MMX and 3DNow! instruction sets. The compiler can or can use plugins to optimize it even further. This means that C is faster because C is popular and so people spend money optimising the C compilers to make better machine code which makes C seem faster. But why was C so popular? Because it could do anything a lot easier than anything else, whether it be hardware or software (unless you''re a hardcore asm programmer). Ditto C++.

Or something like that...

Let''s all start using COBOL!!!

*DarkMage139 bursts out in laughter*

(just kidding)

- DarkMage139
"Real game developers don't change the rules. Real game developers don't break the rules. Real game developers make the rules!"
"Originality (in games) is the spice of life!"

quote:Original post by Muzzafarath

Magmai, I think you responded to the wrong thread :p

- Muzzafarath

Mad House Software
The Field Marshals

yeah, oops, i delete it

quote: Original post by MadKeithV

Original post by Magmai Kai Holmlor

Polymorphism and/or virtual functions are slow operations in C++ because they require late binding of the function call. i.e. Which function gets called at some line is not known or determined until run-time. If you avoid those constructs, C++ code is not noticable slower than C code. (There may be a few more constructs that are slower, but the ones I listed will destroy performance.) Don't ever use a base class pointer to derived class in a speed critical portion of code.


This is not necessarily true at all. You could check my article on optimising C++ ( right here. ) or read "efficient C++", a book on optimising for C++. A single *this pointer dereference might be only a very small percentage of your code, even if it is on your critical path.

Pure virtual function (late) binding is slow. Never use a base class pointer to point to a derived class. Use dynamic casting if you must use abstract base classes. There is much more happening there than a *this... Yes, it could be made much more efficient by using similar methods in your article. It's nearly the same case as the x->y->z->q->ohthisisfast->Onemore->thisiswhatIwant();




Edited by - Magmai Kai Holmlor on June 26, 2000 9:31:15 PM