Is the innate slowness in C++ due to the extra layers of abstraction that the computer must pick through in order to get to 'real' code?
Printable View
Is the innate slowness in C++ due to the extra layers of abstraction that the computer must pick through in order to get to 'real' code?
Innate slowness? I'd say that's due to poor use of the language, not the language itself. Unless you are using assembly, you're probably not going to get much faster, and even the it's not going to be any remarkable speed increase. Of course, it's really tough to say whether the "language" is slow or fast, because that's all dependant on the compiler and your system, etc. not the language itself.
I've heard that it is possible for perfectly written C++ code to have overhead when compared to perfectly written C code due to the nature of the language itself (I'm not examining sytem or compiler, although I know those are huge huge huge factors). I just wanted to know what aspect of the language could cause any possible slowness, and it stills seems that if the overhead exists its because of what I said in my first post.
Poly when you have the plane equation, it is basically the dot product between the normal to the plane and the point in space, and then the distance is added(shortest distance from plane to origin).
I was just wondering, why exacdtly is the distance added?
What does it mean if you don't add the distance? It seems to me if you don't add the distance you might get points passing the test when they in fact should be failing (and vice versa) but I'm not entirely sure how it works, and my book doesn't touch upon that really.
(I PMed you about this but i guess you never got it).
A good C++ programmer with a good compiler will probably produce faster code than an average assembly programmer.
Plus they will code MUCH faster.
I agree with what Bjarne says, "Yes, C++ can be slow...if you don't know how to properly use it."
Maybe; maybe not.Quote:
Originally posted by beege31337
A good C++ programmer with a good compiler will probably produce faster code than an average assembly programmer.
Plus they will code MUCH faster.
When trying to guestimate speed in assembly can you just count the number of instructions? (is each instruction more or less the same in terms of expense?)
Sort-of. Each instruction takes a different number of clock cycles.Quote:
When trying to guestimate speed in assembly can you just count the number of instructions?
When microprocessors were simple, you could look-up the number of cycles required for each particular instruction.
But, things have gotten more complicated.... with parallel processing, predictive branching, on-board cache. Now, they talk in terms of instructions-per-cycle. This spec is an average when performing a standard benchmark test.
The speed issue/question really depends on what you need the speed for, because 90% of the time, processing speed is not a problem. If you need high-speed graphics, then you need to know how to get the most from the graphics drivers and libraries. Maybe you're doing massive scientific "number crunching"... then you need fast floating point calculations. Maybe you're doing transaction processint... then you need fast I/O and disk perfromance.
in addition to what DougDbug said above, most assembly languages also have Pseudo-Instructions. that is, a one line instruction that is valid syntax, but actually gets executed as a series of more simple instructions. thus, just counting the number of instructions used is not very accurate.
Depending on the processor, the reference books will show you how many cycles for that certain instruction. In some cases you could use a different instruction to do the same thing, but one has less clock cycles.
>>due to poor use of the language, not the language itself
Blaming it on either compilers or programmers at all time does
not adress the issue on facts. C++ is a great language
and a wonderful tool for generic programming .but it has its
flaws too.
I am not a experienced C++ programmer.and by no means have
the right credentials to be more in depth.but you cant blame
the driver for a car which is burning oil.
plus there are very few elite programmers who can actually
code C++ and at the same time architect the most
optimal design(like may be Polymorphic OOP).
compilers cant be tailormaid %100 neither.
But, the slowness is not always because of a bad design.
writing a C++ program requires a truly sbstantial amount of
coding compare to for instance, a C version.
couple of examples;
matrix operations in C++ are much slower than C .and
there are aspects of C++ design that making it slower to
access its features.like STL vectore vs ordinary vector.
you can take a coffee break at compilation time for templates.
cheers!
Really? I didn't notice any difference when I started using templates.Quote:
Originally posted by SAMSAM
you can take a coffee break at compilation time for templates.
What's stopping one from doing it the same way in C++ as done in C if you wanted? If you're trying to compare purely the object-oriented aspects of C++ i think you may be missing the point of the question being asked, , even still, if you use the language properly, for a large project, object-oriented C++ will most-likely be less code than a C equivalent, depending on the type of the project. Again, the question doesn't seem to address just oop C++, it sounds as though it's addressing the runtime aspects of a program written in C when compiled on a C compiler and when compiled on a C++ compiler. If not then the languages are impossible to compare because you can't compare features in C++ to ones which simply don't even exist in C.Quote:
Originally posted by SAMSAM
writing a C++ program requires a truly sbstantial amount of
coding compare to for instance, a C version.
Matrix operations? What "operations" are you talking about? Care to elaborate, or are you just happy pulling things out of yer arse :p Pointer arithmetic hasn't changed from C to C++. There isn't any reason that accesing an element of a multidimensional array would be at all slower than in C. There are, of course, very small places where C++ CAN be slower in extremely small respects to a C "equivalent," such as, in some cases, dynamic memory allocation, default constructors called during allocation, exception handling etc., but there is no reason that one can use placement new to get around the default constructor situation and if worst came to worst you can always use C-style dynamic memory allocation in C++. There's nothing stopping you from doing so. Post some real places where C++ can be slower than C, or elaborate on this one, and then I'll give you some credibility. There are places where C++ can [potentially] be slower than a C equivalent, all of which are so trivial and there for good reason that you're not going to find people complaining about them.Quote:
Originally posted by SAMSAM
matrix operations in C++ are much slower than C .and
there are aspects of C++ design that making it slower to
access its features.
First off -- the STL is not the C++ language, and even if it was, you don't have to use vectors as a C++ programmer (I don't). Don't confuse libraries with the language itself. There is no such thing as a vector<> in the C++ language, only in the STL.Quote:
Originally posted by SAMSAM
STL vectore vs ordinary vector.
You think that compiling templates takes a long time? To do the equivalent in C, you would have to completely rewrite each function that was templated for each datatype or value, which would take you much more time for you to write than a templated function would take to be written and compiled (keeping in mind that templated definitions only have to be compiled when you use a form of the templated function, unlike if you were to rewrite the function each time in C), plus, in C++ with templates, you are allowing for future datatypes, which just isn't possible in C without having to manually rewrite the function again and again with slight variances. Not only does it take much longer, but it makes it much more likely to being in bugs and will make your code much longer than it should be.Quote:
Originally posted by SAMSAM
you can take a coffee break at compilation time for templates.
But what it really comes down to is that it all depends on your compiler and system. A "language" can't be slow, it's is just syntax and keywords meaning nothing in terms of speed. It's impossible to compare languages like that because they, themselves, don't have execution time. I understand the point of the question, but it really doesn't have a valid answer.
EDIT: sorry for all the typos. I am really tired :p
Dear oh dear poly i gave you more credit than that. Read your c++ standard specifically section 23 ( containers) and you will see just how wrong that statement is. The stl no longer exists as a library but it has been fully incorporated into the language. Are you saying there is no std::string type too cos thats an stl container.In fact about the only thing the standard doesnt mandate for vector is that it should be a dyamic array. What it does do tho is to specify the properties of a vector as properties of an dynamic array.Quote:
First off -- the STL is not the C++ language, and even if it was, you don't have to use vectors as a C++ programmer (I don't). Don't confuse libraries with the language itself. There is no such thing as a vector<> in the C++ language, only in the STL.
i am teh suck, you are teh win :pQuote:
Originally posted by Stoned_Coder
Dear oh dear poly i gave you more credit than that. Read your c++ standard specifically section 23 ( containers) and you will see just how wrong that statement is. The stl no longer exists as a library but it has been fully incorporated into the language. Are you saying there is no std::string type too cos thats an stl container.In fact about the only thing the standard doesnt mandate for vector is that it should be a dyamic array. What it does do tho is to specify the properties of a vector as properties of an dynamic array.
Polymorphic OOP
"Matrix operations? What "operations" are you talking about?"
Well with my limited knowledge about C++ ,i give u this example:
C++ matrix algebra, via matrix object.
i can point out that in matrix
manupulation or multip(inversion, triangular) and in complex computing
dont you think by representing every number as an
object ,and instatiating it you are creating a unneeded
additional overhead?
each number requires more mem as an object. doesnt it?
wouldnt each calling of an object create additional
overhead.
My haunch may be unfounded. but i would think if i
use OO method for these operation , it would be slower
than its procedural version.
cheers!:)
*note
I have never done any test on any of these topics.
so i am only assuming the results would be what i
think it would.
edit:
iam very new to the usage of matrix manup in C++.
and currently reading on it on the side as iam reading
a C++ book by deitel&deitel.
You know, even though many people may disagree, C/C++ are still high level languages. Since I have registered to the CBoard I've seen numerous arguements about the speed differences of C and C++. I think that we should put them both to the test, with lets say... 200-500 million iterations of some kind? with different kinds of situations. So we could compare exact code, then OOP C++ with C, etc. Then when compiling we would have to make sure that all of the same compile options are selected, etc. There might be some websites with 'statistics' of some kind, but if we do it ourselves then we will all know the kind of sacrifices we give up when using C++ rather than C, and C rather than C++. Does this sound like a good idea?
Yes, but I'm satisified that C++ comes with some overhead which becomes a moot point due to the fact that
1) it isn't all that much overhead to begin with
2) compilers come optimized and come with more options that optimize speed further
3) processors today have speed to burn
an example I was told that comes with some overhead was with inheritance and virtual methods, that the compiler has to check the v table to make sure the correct functions get called and stuff like that, but it really isn't a big deal.
If you want to call a built-in datatype of C++, that's up to you, but for intents and purposes, they're the same in C and in C++. Objects do not ever require extra space unless they use virtual functions. Nonvirtual function calls are done just like in C. There is no overhead in creating and using built-in datatypes (or even userdefined types with nonvirtual member functions).Quote:
Originally posted by SAMSAM
dont you think by representing every number as an
object ,and instatiating it you are creating a unneeded
additional overhead?
each number requires more mem as an object. doesnt it?
wouldnt each calling of an object create additional
overhead.
That's because you literally can't do that in C without manually making a vtable (or some other way of forcing the proper function call). This is one of the features I was talking about where it makes no sense to compare to C because there is no equivalent to it in C. What it comes down to is if you wanted to simulate virtual functions in C, you'd have to manually create and manage your own vtables and do explicit pointer casting, and still not get the benefit of an explicit hierarchy and simple syntax. Your code would not most-likely not be any faster, either. Just a hell-of-a-lot less readable.Quote:
an example I was told that comes with some overhead was with inheritance and virtual methods, that the compiler has to check the v table to make sure the correct functions get called and stuff like that, but it really isn't a big deal.
No, simply because of compiler differences, etc. as well as the fact that you explicitly said OO C++. Why not just use the procedural portion of C++ if you wanted an accurate comparison. You could usually even use exactly the same syntax. If you don't use the procedural portion of C++ then you're just going to be comparing two completely different things so a test would prove nothing. Either way, you're not going to get truely accurate results, and besides, once again, the languages themselves are not "slower or faster" so any tests you do only represent the compiler you're using and your system, not the language.Quote:
You know, even though many people may disagree, C/C++ are still high level languages. Since I have registered to the CBoard I've seen numerous arguements about the speed differences of C and C++. I think that we should put them both to the test, with lets say... 200-500 million iterations of some kind? with different kinds of situations. So we could compare exact code, then OOP C++ with C, etc. Then when compiling we would have to make sure that all of the same compile options are selected, etc. There might be some websites with 'statistics' of some kind, but if we do it ourselves then we will all know the kind of sacrifices we give up when using C++ rather than C, and C rather than C++. Does this sound like a good idea?