Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Theses

Is C truly fast?

This topic is 6617 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

i don''t understand this isn''t C language a specification so aren''t we really talking about the compiler being optimized when we speak of C language being fast

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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!"

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!