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?
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.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.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.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.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 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.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.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.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
Last edited by Polymorphic OOP; 04-11-2003 at 11:46 PM.
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.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.
Free the weed!! Class B to class C is not good enough!!
And the FAQ is here :- http://faq.cprogramming.com/cgi-bin/smartfaq.cgi
i am teh suck, you are teh winOriginally 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.