Announcement

Collapse
No announcement yet.

Is Assembly Still Relevant To Most Linux Software?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Nope

    Originally posted by ciplogic View Post
    You're fully wrong! If you don't write virtual you have the same memory footprint. In fact C++ is a stricter than C, so is less error prone. Like:
    int* array = malloc(sizeof(char)*length); //will give error in C++ not in C so is less likely you will make mistakes in C++.
    Also as you can override new operation, you can use the same C routines (or a custom memory allocator) if you want the same perf caracteristics.

    In the past C++ would do many "invisible copying" (like users copying std::vectors everywhere), and people not trained with C++ or people that would not use Ref and Const Ref, would get worse performance than using C, but this is not because C++ was badly designed, but badly used.

    Still C++ is really the king performance wise as it extensively uses inlining in templates, the "invisible copying" is solved many times by just using constant references or C++ 11 added "copy semantics" so your compiler will remove some copying by itself (with no extra assembly).

    At last I want to congratulate him of using Qt, is really a great framework, also Qml/JS side.
    When I was fully wrong and C++ the King of performance, why is it that most developers still use C instead of C++?

    Btw: I didn't write anything about C++ being better or worse, I just said there were big differences in classes and structs, which in my opinion lead to worse memory management. Don't smoke so much crack, you are really tempered!

    And: I don't see any problem with the example you gave.
    EDIT: Normally you would use n-times the size of an integer, and not a char. But this is a design-issue and might also be voluntary.
    Last edited by frign; 10 April 2013, 01:05 PM.

    Comment


    • Originally posted by frign View Post
      Btw: I didn't write anything about C++ being better or worse, I just said there were big differences in classes and structs, which in my opinion lead to worse memory management. Don't smoke so much crack, you are really tempered!
      In C++ specification, struct is a class with permissions set to public by default!
      Code:
      struct MyStruct{} ;
      is the same with:
      Code:
      class MyStruct{ public: } ;
      If you use classes/structs with virtual, you will have a virtual table pointer, but no one requires you to do so.

      If you talk about some things that are more verbose in C++, are the C++ name mangling to solve conflicts (because of function overloading) but has no final memory runtime issues as far as I'm aware. If you don't want to have this, you can write all C++ code and export functions with
      Code:
      extern "C" {
      (...)
      };
      Originally posted by frign View Post
      When I was fully wrong and C++ the King of performance, why is it that most developers still use C instead of C++?
      This is a non-sequitor (http://en.wikipedia.org/wiki/Non_sequitur_%28logic%29 ): most developers may use C for a lot of reasons, and maybe none is about performance. (mistake explained in detail: http://en.wikipedia.org/wiki/Affirming_the_consequent )

      A link that states that "C faster than C++ is a myth": http://discuss.fogcreek.com/joelonso...ow&ixPost=7461

      In fact even people that are using assembly don't use it always for performance, just 30% of them would do (I'm using your numbers). GCC rewrite in C++ proved to some extend this as I've never heard that compile times grew as GCC is C++ based now. Or LLVM (which from ground-up was C++ based) has a strength of faster compilation than GCC. Cairo (C vectorial graphics library) was at least some years ago slower than the C++ counterpart in Qt: http://zrusin.blogspot.com/2006/10/benchmarks.html

      Where you use the biggest number most developers? Tiobe maybe? ( http://www.tiobe.com/index.php/conte...pci/index.html ). If it is so, why the second most developers pick Java? Is also performance? If you looked to the statistics, Dynamically Typed Languages 29.2% (more than C users which are around 18%) are using a dynamic language (which has some performance limitations/implications).

      The biggest reason I think that C is still powerful is related with interoperability: C is a target language for any language is interoperable with. Java, C#, JavaScript or any other language in Tiobe top 20 (including assembly) with notable exceptions of Transact-SQL and PL-SQL are C aware (sometimes, like in Lua you have to set some hook methods, but is easy to do so). Combined with his long history and that the language is fairly simple to start with (which means in turn that is taught in high-schools and universities) I think is a better reason why people are using C.

      There are transitions that are slower from C to C++, for example Quake3 was fairly light, when Doom 3 was heavy in resources, but was mostly because they were using an interpreter in the back, is not the fault of C++ (I'm not giving excuses though). Rage game engine was light (compared with their competition of end 2011, like Crysis 2) and both were written in C++. Many parts of fast parts of Windows (DirectX comes first to mind) are C++.
      Last edited by ciplogic; 10 April 2013, 01:46 PM.

      Comment


      • Here is a quick small asm hack I made to the radeon r600_shader.c file in mesa. Note it is only two instructions. It sure beats doing a loop with a test in the middle. lets see if you can get a c compiler to beat this .

        static int tgsi_last_instruction(unsigned writemask)
        {
        #if 1
        /*AND input with 0xF to confine the search to the four least significant bits */
        /* use BSR (Bit Scan Reverse) to find the most significant bit position 0 through 3 */
        /* Note: BSR instruction uses source as its destination to return zero if zero
        is its input. Officially documented as an undefined output for zero input but
        behaviour of the BSR instruction just doesn't change the destination register
        contents in this case */

        __asm (
        "and $0x0F, %0\n\t"
        "bsr %0, %0 \n\t"
        : "=&r" (writemask)
        : "0" (writemask)
        : "cc");

        return writemask;
        #else
        int i, lasti = 0;

        for (i = 0; i < 4; i++) {
        if (writemask & (1 << i)) {
        lasti = i;
        }
        }

        return lasti;
        #endif
        }

        Comment


        • Religion

          Originally posted by ciplogic View Post
          In C++ specification, struct is a class with permissions set to public by default!
          Code:
          struct MyStruct{} ;
          is the same with:
          Code:
          class MyStruct{ public: } ;
          If you use classes/structs with virtual, you will have a virtual table pointer, but no one requires you to do so.

          If you talk about some things that are more verbose in C++, are the C++ name mangling to solve conflicts (because of function overloading) but has no final memory runtime issues as far as I'm aware. If you don't want to have this, you can write all C++ code and export functions with
          Code:
          extern "C" {
          (...)
          };

          This is a non-sequitor (http://en.wikipedia.org/wiki/Non_sequitur_%28logic%29 ): most developers may use C for a lot of reasons, and maybe none is about performance. (mistake explained in detail: http://en.wikipedia.org/wiki/Affirming_the_consequent )

          A link that states that "C faster than C++ is a myth": http://discuss.fogcreek.com/joelonso...ow&ixPost=7461

          In fact even people that are using assembly don't use it always for performance, just 30% of them would do (I'm using your numbers). GCC rewrite in C++ proved to some extend this as I've never heard that compile times grew as GCC is C++ based now. Or LLVM (which from ground-up was C++ based) has a strength of faster compilation than GCC. Cairo (C vectorial graphics library) was at least some years ago slower than the C++ counterpart in Qt: http://zrusin.blogspot.com/2006/10/benchmarks.html

          Where you use the biggest number most developers? Tiobe maybe? ( http://www.tiobe.com/index.php/conte...pci/index.html ). If it is so, why the second most developers pick Java? Is also performance? If you looked to the statistics, Dynamically Typed Languages 29.2% (more than C users which are around 18%) are using a dynamic language (which has some performance limitations/implications).

          The biggest reason I think that C is still powerful is related with interoperability: C is a target language for any language is interoperable with. Java, C#, JavaScript or any other language in Tiobe top 20 (including assembly) with notable exceptions of Transact-SQL and PL-SQL are C aware (sometimes, like in Lua you have to set some hook methods, but is easy to do so). Combined with his long history and that the language is fairly simple to start with (which means in turn that is taught in high-schools and universities) I think is a better reason why people are using C.

          There are transitions that are slower from C to C++, for example Quake3 was fairly light, when Doom 3 was heavy in resources, but was mostly because they were using an interpreter in the back, is not the fault of C++ (I'm not giving excuses though). Rage game engine was light (compared with their competition of end 2011, like Crysis 2) and both were written in C++. Many parts of fast parts of Windows (DirectX comes first to mind) are C++.
          If you look it that way, most developers program in C#. It's not about the technical perspective, why C-programs are faster, it's about how you design your software.
          I see you like Wikipedia very much, but I know what non sequitur means (not non sequitor).

          So, it's still a religious question and I guess we'll never rest in a consens.

          Comment


          • Originally posted by frign View Post
            If you look it that way, most developers program in C#. It's not about the technical perspective, why C-programs are faster, it's about how you design your software.
            I see you like Wikipedia very much, but I know what non sequitur means (not non sequitor).

            So, it's still a religious question and I guess we'll never rest in a consens.
            Thanks for fixing my typo, I will double check in future. I use Wikipedia as it states properly most of the times.

            As C++ is the faster than C as you can use the C subset and have the same (baseline performance), but also other constructs (I'm talking here about templates):
            A Google engineer perspective: http://lingpipe-blog.com/2011/07/01/why-is-c-so-fast/
            This guy also seemed to agree that C++ is faster because it can do better inlining: http://radiospiel.org/sorting-in-c-3...faster-than-c/

            I'm still curios of your classes differences from C++ and C struct (a statement you made )

            Comment


            • Definitely a hard topic

              Originally posted by ciplogic View Post
              Thanks for fixing my typo, I will double check in future. I use Wikipedia as it states properly most of the times.

              As C++ is the faster than C as you can use the C subset and have the same (baseline performance), but also other constructs (I'm talking here about templates):
              A Google engineer perspective: http://lingpipe-blog.com/2011/07/01/why-is-c-so-fast/
              This guy also seemed to agree that C++ is faster because it can do better inlining: http://radiospiel.org/sorting-in-c-3...faster-than-c/

              I'm still curios of your classes differences from C++ and C struct (a statement you made )
              Ok, starting with structs and classes: The main difference is that classes in C++ are way more complex than structs in C. This is not a bad thing right away. You can define constructors, destructors and the like, be able to to use templates for flexible typecasting or even overload operators.
              The main issue here is definitely maintainability: You can find many opinions/tests/rants on the Internet claiming one of the languages to be better/faster/stronger/... .
              While on the technical perspective C++ is way more flexible, it remains to be discussed if it is faster. Let's imagine both languages to be equally as fast:

              Given the big flexibility, every C++-programmer has his own coding style. There is no definite way of expressing something in C; you have a big freedom of choice.
              The reason I guess why C is favored in free software projects is the fact, that there are no big gaps when it comes to designing the software.
              10-20 years from now, another programmer will still be able to understand the code, and quite frankly, judging from my own experience, porting C++-code is much more of a pain (especially in Game engines), because of very frequent bad and complex design decisions.

              Nevertheless, you can write great C++ too and horribly design a C program at the same time! It's all about the person writing the code and how the code is structured.
              Especially today's architectures are hard to really "measure". Everything is parallelised and highly dependent on current memory-IO and other small factors. Neither the binary size nor the number of cycles give definite answers about the speed and efficiency of a program. This may be a mystery never to be solved with today's possibilities!

              Comment


              • Originally posted by frign View Post
                Given the big flexibility, every C++-programmer has his own coding style. There is no definite way of expressing something in C; you have a big freedom of choice.
                The reason I guess why C is favored in free software projects is the fact, that there are no big gaps when it comes to designing the software.
                I agree with that point on coding style. You can do OOP, template base, procedural, functional, even event based programming in C++. It's cool, but if you do that in the same project, it will bite you.. C++ may need more discipline, the kind you find more easily in corporate environment.
                Also true is what ciplogic said on binary interface (C defines it, but C++ is implementation dependent).

                But about being faster or slower, I think it boils down to the following:
                - If you misuse C++ features, it will be slower in C++
                - If you try to write yourself in C the features of C++, it will be faster in C++



                Also, source on the the comparison between gcc-c and gcc-cxx on the C and C++ subset.

                Comment


                • Originally posted by frign View Post
                  Ok, starting with structs and classes: The main difference is that classes in C++ are way more complex than structs in C. This is not a bad thing right away. You can define constructors, destructors and the like, be able to to use templates for flexible typecasting or even overload operators.
                  So, classes (or structs) in C++ are a more complex language constructs. But if you don't use virtual (as you don't write typical pointer to functions by hand either in C) inside structs so often, the main difference seems to be for you the methods, which as in C are not defined in the body of the struct/class, right?

                  Originally posted by frign View Post
                  The main issue here is definitely maintainability: You can find many opinions/tests/rants on the Internet claiming one of the languages to be better/faster/stronger/... .
                  While on the technical perspective C++ is way more flexible, it remains to be discussed if it is faster. Let's imagine both languages to be equally as fast:

                  Given the big flexibility, every C++-programmer has his own coding style. There is no definite way of expressing something in C; you have a big freedom of choice.
                  The reason I guess why C is favored in free software projects is the fact, that there are no big gaps when it comes to designing the software.
                  10-20 years from now, another programmer will still be able to understand the code, and quite frankly, judging from my own experience, porting C++-code is much more of a pain (especially in Game engines), because of very frequent bad and complex design decisions.
                  So eventually, the performance (that C++ certainly have accessible some extra features, at least giving hints to compiler, as const references and templates to help compiler to inline your code, in the mean time offering everything that C offers including assembly) is not the reason you think that C over C++ is chosen, right (as your original statement was)?

                  It is that is too flexible and as there are many "ways to shot yourself in the foot", makes eventually that C++ to have a "higher level of entry".

                  I have been a professional C++ developer and I know the template debugging is really painful (it got better with latest CLang and GCC releases). If you use reference counting, you may have hidden cycles that lead to leaks, if you don't use them at all, you still have chances to leak from other module, etc. All these statements I agree with you as I lived them.

                  15 years ago the compilers were not so mature on C++ side. They were good, but not good enough, to say nicely. From a 2006 year, I can say that C++ was good as performance was concerned. With C++ 11, I think that by copy semantics done "automatically", also removed some classes of code inefficiencies.

                  Today this argument doesn't hold water as GCC has many complex optimizations under its belt. If you discuss about opensource projects and most likely we discuss about big ones, many of them were started before year 2000 and naturally most of them would use a form of C. There are big projects in C++ that run fast (LibreOffice, Chrome, LLVM, GCC now, Qt).

                  Also erendorn confirmed this, in a way he did point that using C++ compiler to compile C code will not give any performance regression, so there is no point to use your C compiler excluding you want to save disk space.

                  I can say one thing that I would agree with you: many C++ developers don't have a C mindset thinking that this * operator can make a full multiplication (as is may be hidden by overloading or overriding of the operators that C++ is capable of). In C when you study the language you mostly learn: union types, how types are pushed by pointers or by value, which is a "low level" thinking. This can lead in a way to faster codes, at least for developers that do write code in a rush. In C++ will take 1-2 years to get comfortable with, not just 1-2 months like in C side, so maybe here where the problem lies in your view that C++ is slower. This mentality is also probably why some other people here think that language J is slow. There is a lot of software that is not thought in performance terms (that most C programmers will take it for granted) so maybe this is why that some C++ applications would be better written in C. But in a way, this is why they should be written in C++, but people to be taught only a "fast subset" of it, basically STL, classes where you define a proper copy constructor, use const references where you should, and make your functions const where possible.

                  Comment


                  • Great!

                    Originally posted by ciplogic View Post
                    So, classes (or structs) in C++ are a more complex language constructs. But if you don't use virtual (as you don't write typical pointer to functions by hand either in C) inside structs so often, the main difference seems to be for you the methods, which as in C are not defined in the body of the struct/class, right?


                    So eventually, the performance (that C++ certainly have accessible some extra features, at least giving hints to compiler, as const references and templates to help compiler to inline your code, in the mean time offering everything that C offers including assembly) is not the reason you think that C over C++ is chosen, right (as your original statement was)?

                    It is that is too flexible and as there are many "ways to shot yourself in the foot", makes eventually that C++ to have a "higher level of entry".

                    I have been a professional C++ developer and I know the template debugging is really painful (it got better with latest CLang and GCC releases). If you use reference counting, you may have hidden cycles that lead to leaks, if you don't use them at all, you still have chances to leak from other module, etc. All these statements I agree with you as I lived them.

                    15 years ago the compilers were not so mature on C++ side. They were good, but not good enough, to say nicely. From a 2006 year, I can say that C++ was good as performance was concerned. With C++ 11, I think that by copy semantics done "automatically", also removed some classes of code inefficiencies.

                    Today this argument doesn't hold water as GCC has many complex optimizations under its belt. If you discuss about opensource projects and most likely we discuss about big ones, many of them were started before year 2000 and naturally most of them would use a form of C. There are big projects in C++ that run fast (LibreOffice, Chrome, LLVM, GCC now, Qt).

                    Also erendorn confirmed this, in a way he did point that using C++ compiler to compile C code will not give any performance regression, so there is no point to use your C compiler excluding you want to save disk space.

                    I can say one thing that I would agree with you: many C++ developers don't have a C mindset thinking that this * operator can make a full multiplication (as is may be hidden by overloading or overriding of the operators that C++ is capable of). In C when you study the language you mostly learn: union types, how types are pushed by pointers or by value, which is a "low level" thinking. This can lead in a way to faster codes, at least for developers that do write code in a rush. In C++ will take 1-2 years to get comfortable with, not just 1-2 months like in C side, so maybe here where the problem lies in your view that C++ is slower. This mentality is also probably why some other people here think that language J is slow. There is a lot of software that is not thought in performance terms (that most C programmers will take it for granted) so maybe this is why that some C++ applications would be better written in C. But in a way, this is why they should be written in C++, but people to be taught only a "fast subset" of it, basically STL, classes where you define a proper copy constructor, use const references where you should, and make your functions const where possible.
                    I think these are very smart thoughts! I agree with you.

                    In the ideal case, you have a C++ programmer who thinks like a C programmer, but those worlds seem to be quite divided upon religious hatred and obsession for each one's language.
                    But for me, C is enough. I know C++, but don't like it's design. And when it doesn't make fun, why even program?

                    Comment


                    • Originally posted by frign View Post
                      I think these are very smart thoughts! I agree with you.
                      Thanks!
                      Originally posted by frign View Post
                      In the ideal case, you have a C++ programmer who thinks like a C programmer, but those worlds seem to be quite divided upon religious hatred and obsession for each one's language.
                      But for me, C is enough. I know C++, but don't like it's design. And when it doesn't make fun, why even program?
                      As for me, I think that "C thinking" can be hurtful for many classes of problems, but again this is my experience. Also "C++ thinking" can lead to many classes of problems. Or any "language thinking". A language is a tool to express algorithms for your problems. There are languages that do it better or worse, but none as far as I'm concerned are solving all issues at once.

                      Just to point some kind of problems I know C doesn't address:
                      - A great class of solutions are functional programming (like Lisp, SQL, Haskell) and they can be migrated easily to multi-core and also can avoid many classes of optimization pitfalls.
                      - I also like Ruby (even Ruby seems to be fairly slow) as it has a thinking: "convention over configuration" both inside the language and inside it's most popular MVC web framework (Rails)
                      - to use a GC: this in many classes of problems reduce the coding and the leaks (I know that some will say that GC still have leaks, which I know, but is less likely to have one). Boehm's GC exists out there, but it has the possibility to leak (as is a conservative GC, any int is considered a possible pointer) and is slow too.
                      - C has a fairly poor multi-core experience (also C++) because it doesn't offer immutability warranties. Yes, you can write immutable code, or you can put locks everywhere, but you don't have a language that allows you to set structures immutable (like language D does)
                      - static analysis of the code is fairly weak story in C: there is lint tool, and recently there is Clang's analysis component, but C developers mostly don't use these tools and sometimes they have weird behaviours that could be proven by these analyzers that they are faulty. C# has a great story here, C++ has it too with Visual Studio for XBox edition (John Carmack stated this, yet I never used these tools).
                      - language cannot offer sometimes even the basic bounds checks (which have a performance cost, but in C++ with STL is an opt-in part for a component that you need safety over performance). Performance is important but security of not having your buffer overflows attacks is also important.
                      - to make a DSL like you can with Ruby (aka Monkey patching = to add keywords). You may say that macros can do this, but I kindly disagree: macros can be both hurtful as they can expand the code in a way you don't want, and is really not what I was talking about anyway. Look for tutorials about DSL like this one: Part 1: http://jroller.com/rolsen/entry/building_a_dsl_in_ruby Part 2: http://jroller.com/rolsen/entry/building_a_dsl_in_ruby1

                      In a way C gives a better baseline performance, but is hard to make it work in a big codebase to work with C in some specific problem domains. Still C is better than assembly (to be on topic) in most cases and is certainly fast.
                      Last edited by ciplogic; 11 April 2013, 02:24 AM.

                      Comment

                      Working...
                      X