C++ slowness

This is a discussion on C++ slowness within the C++ Programming forums, part of the General Programming Boards category; Is the innate slowness in C++ due to the extra layers of abstraction that the computer must pick through in ...

  1. #1
    Banned
    Join Date
    Jan 2003
    Posts
    1,708

    C++ slowness

    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?

  2. #2
    Programming Sex-God Polymorphic OOP's Avatar
    Join Date
    Nov 2002
    Posts
    1,078
    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.

  3. #3
    Shadow12345
    Guest
    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).

  4. #4
    booyakasha
    Join Date
    Nov 2002
    Posts
    208
    A good C++ programmer with a good compiler will probably produce faster code than an average assembly programmer.
    Plus they will code MUCH faster.

  5. #5
    Used Registerer jdinger's Avatar
    Join Date
    Feb 2002
    Posts
    1,065
    I agree with what Bjarne says, "Yes, C++ can be slow...if you don't know how to properly use it."

  6. #6
    Xei
    Xei is offline
    Registered User Xei's Avatar
    Join Date
    May 2002
    Posts
    719
    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.
    Maybe; maybe not.

  7. #7
    Shadow12345
    Guest
    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?)

  8. #8
    Hardware Engineer
    Join Date
    Sep 2001
    Posts
    1,398
    When trying to guestimate speed in assembly can you just count the number of instructions?
    Sort-of. Each instruction takes a different number of clock cycles.
    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.

  9. #9
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    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.

  10. #10
    Xei
    Xei is offline
    Registered User Xei's Avatar
    Join Date
    May 2002
    Posts
    719
    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.

  11. #11
    Registered User SAMSAM's Avatar
    Join Date
    Nov 2001
    Posts
    218
    >>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!

  12. #12
    Used Registerer jdinger's Avatar
    Join Date
    Feb 2002
    Posts
    1,065
    Originally posted by SAMSAM
    you can take a coffee break at compilation time for templates.
    Really? I didn't notice any difference when I started using templates.

  13. #13
    Programming Sex-God Polymorphic OOP's Avatar
    Join Date
    Nov 2002
    Posts
    1,078
    Originally posted by SAMSAM
    writing a C++ program requires a truly sbstantial amount of
    coding compare to for instance, a C version.
    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
    matrix operations in C++ are much slower than C .and
    there are aspects of C++ design that making it slower to
    access its features.
    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
    STL vectore vs ordinary vector.
    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
    you can take a coffee break at compilation time for templates.
    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.

    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.

  14. #14
    Skunkmeister Stoned_Coder's Avatar
    Join Date
    Aug 2001
    Posts
    2,572
    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.
    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.
    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

  15. #15
    Programming Sex-God Polymorphic OOP's Avatar
    Join Date
    Nov 2002
    Posts
    1,078
    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.
    i am teh suck, you are teh win

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21