Announcement

Collapse
No announcement yet.

Is Assembly Still Relevant To Most Linux Software?

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

  • #11
    Originally posted by lesterchester View Post
    BSDs are so insecurity that you probability only need to write your code in C, C++ or even shell to be successful.
    zomg, so is SLOWlaris. just moving a mouse breaks that shit. Thank Linus for Linux.

    Comment


    • #12
      Originally posted by lesterchester View Post
      But because of advances in CPU power, such refinements and sleekness are not needed for most apps you use today.
      Man, how fast could our machines be when this wouldn't be the dominant opinion: Optimizing code? What for, get more RAM and a faster CPU!

      Comment


      • #13
        xls? *sigh*

        While not surprising, extremly disappointing is this little bit:
        Raw results

        The raw results from my analysis are stored in Google Docs at

        http://goo.gl/6z2C8

        for anybody else who might be interested. The raw data there works OK, but with limited success. The spreadsheet stored there is already quite slow, plus the many extra cells used to help with analysis did not work at all - maybe I overstepped the limits of Google Docs. Given that, an extra copy in a better format is also attached here for reference.
        The disappointing bit of course is that it is in excel, or at least saved to an xls file. I would have expected that the 'better format' where an ods (Open Document Spreadsheet). But then again, while Linaro is a linux group, for linux on arm, I'm pretty sure most just use Windows, Office and just play with Linux via a VM.

        Comment


        • #14
          Originally posted by TemplarGR View Post
          This is not surprising at all. There is a myth that programming in assembly produces faster executable code, but this is not always the case. It enterily depends on the programmer's ability. Many times a compiler produces better executables than hand written assembly, and is less prone to errors, not to mention developing in assembly takes ages...

          There is absolutely no point in using it today, except for corner cases.
          I agree with you, though as others pointed out you'd have a pain convincing your compiler to generate good code for SIMD instructions, and that's why FFmpeg still uses a lot of hand-optimized asm code.

          There's another indirect use of asm which the Linaro guy didn't mention: runtime code generation, such as JIT. An example is Google v8 Javascript engine.

          Comment


          • #15
            Embedded Systems

            Even embedded-systems-developers are almost entirely using C instead of ASM.
            For professionals however, knowing ASM is essential to write efficient C-programs, as you know how it works behind the scenes, are able to check the compiler-output and know about certain tweaks to write better and faster code. Apart from that, it has actually lost much relevance in real applications, but will never be surpassed by C when it comes to certain functionality (fixed point arithmetic, ...) which just isn't expressable simply in higher-level-languages.
            I am glad to see most software is still written in C and not C++, because non-OO software comes closest to what the CPU actually handles and thus you might not be encouraged to write inefficient code, even though by today's standards, the bottlenecks are almost always too small to be even noticed.

            The big power of compilers is that they can apply architecture-specific tweaks to the written code which the normal programmer would only know after having read hundreds of pages of documentation.
            Especially today, as we have so many different architectures, writing portable code is essential. And even though I personally am a big fan of ASM, as the programs are nice and small, the readability and portability of a well-written C-program is hard to beat.

            Comment


            • #16
              Originally posted by TemplarGR View Post
              This is not surprising at all. There is a myth that programming in assembly produces faster executable code, but this is not always the case. It enterily depends on the programmer's ability. Many times a compiler produces better executables than hand written assembly, and is less prone to errors, not to mention developing in assembly takes ages...

              There is absolutely no point in using it today, except for corner cases.

              In fact, we are rapidly approaching an age where almost all programs will be written in managed languages like Java and C#. Virtual machines have come a long way in speed, and with multicores now the norm, managed code can be as fast or sometimes even more than unmanaged code.
              " There is a myth that programming in assembly produces faster executable code, but this is not always the case. "
              nice paradox (y)

              assembly will never die for compilers will never get as good as a human can
              for a human can think, a human can cheat and a compiler can only do what it has been told to do by a human

              anyway, i seen with perf top that memcpy() was slower then it should be
              so i spent some time making my version of memcpy(), and it was 2-3 times faster then (also hand made) glibc default one
              then i updated the systems glibc to find out its memcpy() gotten faster then my version by some 50%
              now i have a plan to extend my version further

              if i let a (any) compiler make a version of memcpy(), it would be slower, sometimes a lot slower
              even thou the compiler has a template just for memcpy, it cant know exactly how it's gonna be used
              it can know if it can use sse(1234), but youl'd have to first tell it and still it would be slower then my version that is slower then what glibc ppl made

              and yes, speed matters in real time interactive programs
              you can, if careful, make a fast program in C++(maybe even C#, idk) but if you want the fastest that can be you need asm in some spots and lots of benchmarks

              Comment


              • #17
                Nice

                Originally posted by gens View Post
                " There is a myth that programming in assembly produces faster executable code, but this is not always the case. "
                nice paradox (y)

                assembly will never die for compilers will never get as good as a human can
                for a human can think, a human can cheat and a compiler can only do what it has been told to do by a human

                anyway, i seen with perf top that memcpy() was slower then it should be
                so i spent some time making my version of memcpy(), and it was 2-3 times faster then (also hand made) glibc default one
                then i updated the systems glibc to find out its memcpy() gotten faster then my version by some 50%
                now i have a plan to extend my version further

                if i let a (any) compiler make a version of memcpy(), it would be slower, sometimes a lot slower
                even thou the compiler has a template just for memcpy, it cant know exactly how it's gonna be used
                it can know if it can use sse(1234), but youl'd have to first tell it and still it would be slower then my version that is slower then what glibc ppl made

                and yes, speed matters in real time interactive programs
                you can, if careful, make a fast program in C++(maybe even C#, idk) but if you want the fastest that can be you need asm in some spots and lots of benchmarks
                That sounds interesting. Did you commit your improved version to glibc upstream?

                Comment


                • #18
                  Originally posted by frign View Post
                  That sounds interesting. Did you commit your improved version to glibc upstream?
                  no, i made it in FASM
                  my version was faster cuz glibc one was copying 8bytes at a time, even thou it sayd it is an sse2 version (sse can copy 16bytes at a time)
                  still my version would be faster if glibc was using its proper sse2 version, for i made a simpler logic
                  now the ssse3 version that is faster then mine is faster only in few cases when the source and dest are 1byte unaligned (and with blocks way bigger then the cpu cache, that i can optimize rather easy but am lazy)

                  then there is Agner Fog's version, that i dont quite understand
                  from what i seen from it a compiler cant make anything like that, at least not without heavy care from the programer

                  bdw, string operations are another case where assembly can make a big difference

                  Comment


                  • #19
                    Originally posted by zanny View Post
                    What? This isn't about managed vs unmanaged, and if anything the Linux development space is trending towards Qt, which is C++ and native, since Java is a slow boring piece of crap, and C# (mainly Xamarin) has been disowning the Linux developer scene hardcore. Neither are supported across mobile platforms either, which is key, and something that Qt actually has going for it as well, and as GTK and Gnome get its act together it remains a competitor.

                    Java is slow? Have any proof of that? And Java runs on most Mobile phones out there. Where did you get your info, or are you spewing facts from your hind quarters?

                    Comment


                    • #20
                      Mixed messages

                      While the report lists some valuable software, even the Linux kernel itself, as using assembly, it then concludes that "that most of the Assembly code has little value"? Sounds like someone is spinning an agenda, here.

                      Comment

                      Working...
                      X