Page 2 of 18 FirstFirst 123412 ... LastLast
Results 11 to 20 of 177

Thread: Is Assembly Still Relevant To Most Linux Software?

  1. #11

    Default

    Quote 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.

  2. #12
    Join Date
    Jan 2013
    Posts
    1,116

    Default

    Quote 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!

  3. #13
    Join Date
    Jan 2007
    Posts
    418

    Default 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.

  4. #14
    Join Date
    Oct 2008
    Posts
    110

    Default

    Quote 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.

  5. #15
    Join Date
    Oct 2012
    Location
    Cologne, Germany
    Posts
    308

    Cool 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.

  6. #16
    Join Date
    May 2012
    Posts
    534

    Default

    Quote 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

  7. #17
    Join Date
    Oct 2012
    Location
    Cologne, Germany
    Posts
    308

    Thumbs up Nice

    Quote 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?

  8. #18
    Join Date
    May 2012
    Posts
    534

    Default

    Quote 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

  9. #19
    Join Date
    Sep 2011
    Posts
    161

    Default

    Quote 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?

  10. #20

    Default 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •