Dev.SN ♥ developers
Sections
Dev.SN
Subsentient writes:
"I'm a C programmer and Linux enthusiast. For some time, I've had it on my agenda to build the new version of my i586/Pentium 1 compatible distro, since I have a lot of machines that aren't i686 that are still pretty useful.
Let me tell you, since I started working on this, I've been in hell these last few days! The Pentium Pro was the first chip to support CMOV (Conditional move), and although that was many years ago, lots of chips were still manufactured that didn't support this (or had it broken), including many semi-modern VIA chips, and the old AMD K6.
Just about every package that has to deal with multimedia has lots of inline assembler, and most of it contains CMOV. Most packages let you disable it, either with a switch like ./configure --disable-asm or by tricking it into thinking your chip doesn't support it, but some of them (like MPlayer, libvpx/vp9) do NOT. This means, that although my machines are otherwise full blown, good, honest x86-32 chips, I cannot use that software at all, because it always builds in bad instructions, thanks to these huge amounts of inline assembly!
Of course, then there's the fact that these packages, that could otherwise possibly build and work on all types of chips, are now limited to what's usually the ARM/PPC/x86 triumvirate (sorry, no SPARC Linux!), and the small issue that inline assembly is not actually supported by the C standard.
Is assembly worth it for the handicaps and trouble that it brings? Personally I am a language lawyer/standard Nazi, so inline ASM doesn't sit well with me for additional reasons."
(Score: 5, Interesting) by mindriot on Saturday March 08 2014, @09:19AM
That depends on what kind of code you're working with. When you need to make the most of SIMD instructions, there's no way around assembly. I use the Eigen matrix library [tuxfamily.org] a lot in my day-to-day work (IMHO the best C++ matrix library out there in terms of usability and performance), and under the hood both make extensive use of vectorized code (for an example, dig into the Eigen sources [bitbucket.org]). The library user never has to see this or worry about it; but it is the underlying assembly code for vectorization that makes these libraries as fast as they are.
That said, personally I'm quite happy I haven't had to deal with such code myself for quite some time. Such assembly coding is necessary for these library developers, but I'd rather stick to developing my higher-level code than having to fiddle with such details. YMMV :)
soylent_uid=$(echo $slash_uid|cut -c1,3,5)
(Score: 2, Interesting) by FatPhil on Saturday March 08 2014, @03:40PM
> I use the Eigen matrix library a lot in my day-to-day work (IMHO the best C++ matrix library out there in terms of usability and performance)
How the fuck is watching such obvious self-contradiction "interesting"?
"Use assembly!"
followed by
"Use C++!"
You, and some fuck-nutted moderators, have fundamentally misunderstood the purpose of high level languages such as C++ and of libraries. *Someone else* writes the asm, and packages it up in a library that you can link to from your high level language of choice.
Making a public pledge to no longer contribute to slashdot
(Score: 3, Informative) by mindriot on Saturday March 08 2014, @11:12PM
Wow, that's quite some language there. Had a bad day?
You must have missed the part where Eigen is written in C++ code which uses ... inline assembly statements.
In other words, while the user of this library may get to avoid inline assembly code, the developer doesn't avoid it. So, getting back to the original question, if you'd like me to be more specific: most of the time, you'll be fine writing high-level code and using libraries which may or may not use inline assembly. If you're the one developing said library, or you need to seriously get the most performance out of your code especially SIMD instructions , assembly can still be worth it.
soylent_uid=$(echo $slash_uid|cut -c1,3,5)