• Advertisement

Archived

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

Is C truly fast?

This topic is 6442 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
The reason C is said to be "fast" is due to the fact that it is possible to optimise it to buggery. it is also very streamlined (not sure if that''s the right word to use) compared to VB, which is quike frankly ugly. if C was a jet powered car then VB is lawn mower. anyway...

although C isn''t a low-level language, you can input raw assembly code in the middle of it to speed things up.

anyway, C is rather slow compared to pure 32bit assembler. something is only as fast as the things your comparing it to.

C-ASM: slower
C-C++: roughly the same
C-Pascal: faster
C-Basic: much faster
C-VB: even faster
C-Java: faster (speed depends on the Java implementation).

MENTAL

Share this post


Link to post
Share on other sites
quote:

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();



Have you tried it?
Adding virtual functions adds a vtable pointer to an object. That''s a little added space complexity. Resolving the class of the abstract class can sometimes be done at compile-time. That''s no additional overhead.
Worst-case scenario, it cannot be resolved until run-time. In this particular case, whatever you do, you will need a way to resolve the type of the class yourself. This is most likely not much faster ( or even slower ) than the way your C++ compiler handles it.
So why make your code more complex for something that the compiler provides?

Note, I am NOT saying that you should use polymorphism in every nook and cranny. But when it''s useful, don''t shy away from it, unless you have VERY good reason to avoid that small amount of overhead.


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
Guest Anonymous Poster
quote:
Original post by s9801758
But C allows a lot of language constructions that are very close to lower level languages or even the way the processor does it.

the question is, which processor ? ( hint: transmeta crusoe, pixelfusion fuzion )
quote:
Original post by MENTAL
anyway, C is rather slow compared to pure 32bit assembler.

oh yeah, have you tried it ? i was stunned to see what your average VC can do in optimization, and i thought i know asm ...

So, language itself is NEVER fast or slow, its the hardware+compiler that make it slow or fast.

however, Tao of Programming says ...
1.2
The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now there are ten thousand languages.

Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

But do not program in COBOL if you can avoid it.


Share this post


Link to post
Share on other sites
The Tao is truly wise, except it forgot Snowball, the OOP Cobol.

-----------------------------

A wise man once said "A person with half a clue is more dangerous than a person with or without one."

Share this post


Link to post
Share on other sites
quote:

Note, I am NOT saying that you should use polymorphism in every nook and cranny. But when it's useful, don't shy away from it, unless you have VERY good reason to avoid that small amount of overhead.




Like drawing pixels on the screen I used a look-up table & a base pointer (& virtual functions) to get the screen color on a "Corwin's 'Game of Life'" type assignment. Needless to say, the lookup table was a bit faster.

Let us agree that line per line, C is faster than pascal; which is the only apple-to-apple comparision.

Comparing C to C++ just doesn't work because they are different programming ideas. If you don't use the C++ specific stuff with C++, they are the same. If you simulate the C++ stuff in C (pointer tables & what-not) they are the same.


P.S. (I HATE COBOL - and Fortran too)



Edited by - Magmai Kai Holmlor on June 26, 2000 9:40:54 PM

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Magmai Kai Holmlor
Let us agree that line per line, C is faster than pascal; which is the only apple-to-apple comparision.


AARGHH, WRONG !
its up to COMPILER not the language. i can write C compiler that gives you total bullshit slow code.
you can only compare COMPILERS not languages !!!


1.1
.....If the Tao is great, then the operating system is great. If the operating system is great, then the compiler is great. If the compiler is greater, then the applications is great. The user is pleased and there is harmony in the world.




Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster

AARGHH, WRONG !
its up to COMPILER not the language. i can write C compiler that gives you total bullshit slow code.
you can only compare COMPILERS not languages !!!




Umm, no, that's wrong!
You can write a slow C compiler, but you can't write a C++ compiler that generates faster code than a fully-optimised binary code routine.
There are INHERENT overhead issues that depend on the language you use, and those are things you cannot break without breaking language compatibility. So I think the original poster was right in saying that for some languages, you can have faster code than other languages - depending on the constructs you use.




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.

Edited by - MadKeithV on June 27, 2000 4:57:14 AM

Share this post


Link to post
Share on other sites
eh... guys....
assembler isn''t really compiled.... it is conevereted....
because assembeler is a mnemonic(?) for machine language. So in a way it is not compiled.

And let''s not get into a silly discussion here cause everyone just codes what he or she likes...ok?


EOT MR Master

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by MadKeithV
You can write a slow C compiler, but you can''t write a C++ compiler that generates faster code than a fully-optimised binary code routine.


You still didnt get it. its COMPILER+HARDWARE that makes it slow or fast, not the language, semantics, grammer, syntax or mnemonics. YES I CAN design a processor that runs c++ or JAVA faster than anything else, and also C++ compiler for it.

of course theres third, several magnitudes more important factor that will determine speed of the application, and thats PROGRAMMER.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
You still didnt get it. its COMPILER+HARDWARE that makes it slow or fast, not the language, semantics, grammer, syntax or mnemonics. YES I CAN design a processor that runs c++ or JAVA faster than anything else, and also C++ compiler for it.



I was going to say something really rude, but I decided to swallow it...
In fact, I''m not even going to bother telling you why you are wrong, since obviously you won''t listen.
If you think I don''t know what I''m talking about, you obviously have no idea who I am. Your loss. Just stick to your deluded ways then.





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 social functions will be disabled from now on.

Share this post


Link to post
Share on other sites
Some thing that Anonymous Poster, doesn''t seem to understand that discussed here are "relative" speeds. That means the time certain different lang''s take to perform a given task. Although it matters how the compiler is programmed, it is generaly known that one lang is relatively slower than another (see list way up). So in a way COMPILER = somewhat important, and as for hardware, the whole job of a compiler is to translate between one lang and oppcodes, so when oppcodes are concerned = nomater what speed or system the speed ration between lang''s is still the same. So hardware = doesn''t matter. ok? got it?



EOT MR Master

Share this post


Link to post
Share on other sites
Ok, I''m apparently missing something. I always thought machine code was machine code. You should be able to compile Pascal, C, or a C++ program into the same machine code (which would be compiler dependant). Once it''s in machine code it would obviously run at the same speed. The compiler is just basically looking at what the programmer wrote, realizing what it wants (ie, "Hello World" printed to the screen) and writes the code "in it''s own words", ie, in machine code. It would seem to me that all programs (that compile into machine code) COULD run at the same speed if the compiler was smart enough. Am I missing something here?

Share this post


Link to post
Share on other sites
Awright, it was about time for another flame war!!

Just thought I''d let you guys know that work HAS been done on making a C++ processor. That is, that the constructs of C++ would have an almost 1:1 analog in machine code. Using this system, C++ would be faster than C.

People seem to think that C is faster because we all know (vaguely) what each line of code will translate to in assembly. Of course, when you learned that, it was 8086 assembly. What uses that anymore? Almost nothing. Pentium III processors are so complicated that I don''t even want to think about it. I''m just a software guy.

Technically, the machine very much does matter. So does the compiler, absolutely. So the question you need to ask is this:
On machine X, which is faster: Microsoft Visual Studio 6.0 C++, or Microsoft Visual Studio 6.0 C, using these specific constructs to accomplish the same task?

Then, my friends, you can get a definitive answer. And to get that answer, just write some test proggies and time them!

In the end, you may find that speed is not as important as ease of code maintenence.

Share this post


Link to post
Share on other sites
Everything is converted in machine code in the end. There is no such thing as a C++ processor, becuase it is all machine code. Everything goes in this order.

Language
then
Assembly
then
Machine language

Thats how the compiler works (very very very basically).

Now, Im going to explain why, if they made C code run slower C++ code would also run slower. C++ is based on C.

The End.




-----------------------------

A wise man once said "A person with half a clue is more dangerous than a person with or without one."

Share this post


Link to post
Share on other sites

  • Advertisement