If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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

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

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

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

" 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

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

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

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.