Originally posted by lesterchester
View Post
Announcement
Collapse
No announcement yet.
Is Assembly Still Relevant To Most Linux Software?
Collapse
X
-
Originally posted by lesterchester View PostBut because of advances in CPU power, such refinements and sleekness are not needed for most apps you use today.
Comment
-
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
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.
Comment
-
Originally posted by TemplarGR View PostThis 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.
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
-
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
-
Originally posted by TemplarGR View PostThis 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.
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
-
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
Comment
-
Originally posted by frign View PostThat sounds interesting. Did you commit your improved version to glibc upstream?
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
-
Originally posted by zanny View PostWhat? 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
Comment