TIOBE's Language-Popularity Index Sees A New Top 10 Language: Assembly (tiobe.com) 348
TIOBE's "Programming Community Index" measures the popularity of languages by the number of skilled engineers, courses, and third-party vendors. Their July report indicates that Assembly has become one of the 10 most popular languages:
It might come as surprise that the lowest level programming language that exists has re-entered the TIOBE index top 10. Why would anyone write code at such a low level, being far less productive if compared to using any other programming language and being vulnerable to all kinds of programming mistakes? The only reasonable explanation for this is that the number of very small devices that are only able to run assembly code is increasing. Even your toothbrush or coffee machine are running assembly code nowadays. Another reason for adoption is performance. If performance is key, nobody can beat assembly code.
The report also noted that CFML (ColdFusion) jumped from #102 to #66, Maple from #94 to #74, and Tcl from #65 to #48. But Java still remains the #1 most-popular language, with C and C++ still holding the #2 and #3 positions. Over the last five years, C# and Python have risen into the #4 and #5 spots (made possible by PHP's drop to the #6 position) while JavaScript now holds the #7 position (up from #9 in 2011). Visual Basic .NET came in at #8, and Perl at #9.
The report also noted that CFML (ColdFusion) jumped from #102 to #66, Maple from #94 to #74, and Tcl from #65 to #48. But Java still remains the #1 most-popular language, with C and C++ still holding the #2 and #3 positions. Over the last five years, C# and Python have risen into the #4 and #5 spots (made possible by PHP's drop to the #6 position) while JavaScript now holds the #7 position (up from #9 in 2011). Visual Basic .NET came in at #8, and Perl at #9.
wat (Score:2)
The only reasonable explanation for this is that the number of very small devices that are only able to run assembly code is increasing. Even your toothbrush or coffee machine are running assembly code nowadays.
Wait, my toothbrush or coffee machine is capable of running assembly code? Normally, they only run bytecode that's been compiled from assembly code. I got my toothbrush for ten bucks with a charger, that's awesome! What's in there, an assembler or an interpreter? Either way, it must have a seriously overkill microcontroller.
These ratings are based on search results. Pardon my skepticism. From what I can tell, more and more microcontrollers are being programmed in C these days.
Re: (Score:3)
Do you understand what 'programmed' in assembly means? Does not mean there is an assembler or interpreter on the device, only that the source code was written in assembler for some processor architecture, assembled to a binary image, and then programmed into ROM/FLASH/etc on the target device.
'Programmed in C' does not mean your fancy toothbrush has to have GCC running on it to be able to do its thing any more than 'programmed in assembler' does.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
I prefer to do smaller Cs in Assembler. In real time systems it can be important to know EXACTLY how many cycles an set of instructions will take. You can also carefully craft a routine to have exactly the same run times no matter the branch it takes, which can be very important in areas where reliable timing is key (e.g. if you want to avoid that your encryption get broken by a timing attack, or when you're dealing with crap like the USB protocol which barfs the moment you're just a liiiiittle bit off).
Re: (Score:2)
That C was supposed to be mC.
Say, when were we supposed to get unicode support?
Why Unicode was cut from /. (5:erocS) (Score:2)
Say, when were we supposed to get unicode support?
As soon as it's possible to prevent all current and future directionality override control characters from fuccing with the layout [slashdot.org].
Re: (Score:2)
And you thought you were joking.
Re: (Score:2)
My coffee machine runs on Java direct - none of this assembly or bytecode nonsense!
This is hilarious not only for the pun on coffee, but also because some coffee machines actually do run on Java. I am actually quite interested how that would work - I believe you can compile Java to regular assembly, as I believe Android 5+ does, but I'd imagine it wouldn't be worth it for that case since C would do the job too. So if you use a regular JVM, or even a customized version, I'd imagine you'd need some sort of proper OS too.
Not convinced (Score:5, Informative)
I've been involved in firmware development for implantable medical devices as well as other devices and it's simply not true that assembly has much use this day in age. Unless you are coding for one of the small memory footprint AVR or PIC devices you are not going to get better results working in assembly.
Re: (Score:2)
Nut even on those devices you need assembler to do some basic stuff. Writing the C library, writing the OS, writing interrupt handlers, making use of system level machine options (there's no "C" operation to control caching for instance).
Re:Not convinced (Score:5, Insightful)
There are also some pretty stupid limitations in C, for example, no access to the "carry" bit. Usually it does not matter, but if it does, embedding assembler is the way to deal with that.
Re: (Score:3)
And optimizers are sometimes stupid. Ie, you do the equivalent of rotate and such and it doesn't figure out to replace with a single instruction. Don't always need it, but is handy for optimizing crypto type stuff.
Re: (Score:2)
There are also some pretty stupid limitations in C, for example, no access to the "carry" bit.
This isnt a "stupid" limitation of C. Its just that the C abstract machine isnt low level in spite of the claims of modern C programmers.
In 1980 if you said that C was a low level language you would have been laughed at. By 1990 C had become so popular that the collective wishful thinking of C programmers erroneously adopted the notion that C was low level.
Now here we are today. C programmers are convinced that C is low level and cant imagine how anyone could have the knowledge to beat the compiler, be
Re:Not convinced (Score:5, Interesting)
There are good reasons to work in assembly, particularly in systems programming. Or if you don't want to pay licensing fees for an OS, you may need to implement functions in assembly that are not possible in a high level language like C (manipulating machine state registers, implementing barriers, etc.).
I have been using assembly for various architectures for my entire career and most of my teenage life, I don't see any reason why it would ever go away. Mostly the number of people doing high level development has increased so radically that it honestly surprises me that it makes #10. Optimization for performance is definitely not a reason I'd expect to see asm hit #10 - most companies don't spend enough time on their applications to get to the point where they can optimize intelligently, and writing something in assembly is not always or a performance enhancer.
Re: (Score:2)
Re: (Score:2)
Funny, I never had trouble accessing registers using C
Memory mapped registers? Sure, no problem. But you also have I/O mapped registers which require special instructions, as well as things like the arm machine state registers which have a family of instructions you need to use. Then there are things like memory and instruction barriers, they also require specific instructions that you cannot make C emit without a library call to an asm function. You have cache invalidates, semaphore mechanisms etc. All o
Re: (Score:2)
I never had trouble accessing registers using C
Odds are you do not know all of the registers on your chip.
Re: (Score:2)
I've been involved in firmware development for implantable medical devices as well as other devices and it's simply not true that assembly has much use this day in age.
I've been involved in firmware development for small devices. In my (probably limited compared to you) experience, the ability to read and understand assembly is just as important as it's always been in that space, even if not a single line of deployed code is written in assembly. If I was hiring someone, I would put that in the job requirements. For TIOBE's statistics-gathering purposes, that may well translate to "assembly programmer wanted".
Re: (Score:2)
Then I assume you're paying a third party to supply libraries for you, operating systems, startup code, BSPs, etc. Which means those third parties are using the assembler even if you aren't. I do embedded for a living, and I have to do assembler - not everyone working on the software does but some people do.
Comment removed (Score:4, Interesting)
Re: (Score:2)
We're selling millions each year, and it's amazing the sort of silly things they do to save 2 cents, like having a processor that's just a bit too small. Though for what we have and the price customers want, we almost never have enough memory to be able to compile w/o optimization while debugging.
Assembly language for what machine? (Score:5, Insightful)
Assembly for what processor architecture? (Score:5, Insightful)
X86, ARM, AVR, IBM360, PDP8, or what? Just saying 'assembly' is not all that interesting. Processor architecture(s) would be interesting to know.
Re: (Score:2)
Re: (Score:2)
Just imagine how many virtual C64s you could host on a modern server. Augment the original instruction set with 32-bit and 64-bit modes, and you might really have something. I know it's not likely; but the thought of being able to run Jumpman in backwards compatability with a modern office suite kind of gives me the feel-goods. We'd probably have to use timers to event-trigger each instruction for games that ran flat out with delay loops!
Re: (Score:2)
For a 6502 renaissance, look no further than the dozens of new NES games released in the past few years.
Re: (Score:2)
Just wait till web-assembly comes out ... (Score:2)
... or are they mixing assembly up with web-assembly?
That would explain a thing or two.
Ahem (Score:5, Insightful)
A) Why don't you ask them and learn?
B) I politely disagree that they are automatically "far less productive". I am an embedded programmer and have only used tiny amounts of assembly over the last decade. However, if I had more tiny projects, and my bosses weren't akin to cats chasing flashlight spots to where I could stick with the same processor for more than a year, I'd consider it for sure. Why? Because I never seem to get to just "code and go" anymore. As an example, last week I had to reinstall my multi-gigabyte Eclipse IDE for the SECOND time this past year (this time due to a debugger corruption). In such IDEs, all the higher libraries (and their paths) need to be in place, and compiled too (which doesn't always go perfectly). Whereas my former officemate would open any text editor (his was Corel Word Perfect(!)) to write his assembly, then compile on the command line, then upload the binary.
I don't know how many hours I've spent learning and fixing IDEs. Then, a year to two later, the IDE changes again after the chip's OEM "upgraded" it!
Re: (Score:2)
That's not a problem with "compiled code". That's the problem that Eclipse blows goats for crack. Switch to IntelliJ (or the other language products by the same guys) - still takes a while to load, but at least it won't corrupt itself.
Of course, Notepad++ is good enough for most simple C/C++ programs, or small bugfixes. Anyone recommend a decent Linux equivalent? And no, if I wanted VIM, I already have VIM, thanks.
Re: (Score:2)
Notepadqq?
Re: (Score:3)
Re: (Score:2)
"I''ve heard on various occasions that even people forced to use windows for a text writing job are more productive when using their own favourite editor, like vi, then importing the result into the fancy wysiwyg thing supposed to be used, and finishing up with some formatting work. You too could install a fave text editor and use that. What's stopping you?"
The 80s were over 30-35 years ago.
Compiling toothbrush code with GCC (Score:5, Informative)
Here's a electric toothbrush reference design [ti.com.cn] from Texas Instruments.
Here's the MSP430G22x0 microcontroller used in the design [ti.com].
Here's a list of software tools for that microcontroller [ti.com]. The list includes something called "GCC", which they say is an "Open Source Compiler for MSP Microcontrollers".
Here's a page from Renesas about electric toothbrush designs [renesas.com].
Here's a list of software tools for Renesas processors [renesas.com]; they list C compilers for the R8C and RL78 microcontrollers, as mentioned in the previous page.
So don't assume all the code in your toothbrush was written in assembler language; some of it may have been written in C, although some of the low-level library routines might be written in assembler (or an asm in the C code).
Re: (Score:2)
And, yes, there are people who want to hack their toothbrushes [allaboutcircuits.com].
(For more fun, try a Web search for "toothbrush microcontroller" - that's how I found all those links.)
Re: (Score:3)
According to TFA, the electric toothbrush reference design is also suitable for 'personal care items'.
Never in a thousand years would I have thought such a stodgy outfit as TI would have ever created a reference design for a vibrator.
Not to mention the sad state of affairs when said vibrator needs a microprocessor. Now you have no idea with the thing is really doing when you turn it on. This is a really fucking weird world.
Re: (Score:2)
Without an MCU, how would an iBrator vary its rate in sync with the porno you're watching?
Years too late... (Score:2)
Re: (Score:2)
That is tragic. While rarely used, it gives you a far better understanding of how things work. Seems most engineering students these days aim for being mediocre.
Explanation is bogus (Score:2, Interesting)
The smallest device I have written code for is a PIC with 512 bytes of RAM and 256 bytes of ROM. It had a C compiler. It is also lacking in connectivity for making trendy IoT devices. So what are all these devices that can only run assembly code?
I think a more likely explanation is that fad languages come and go, and now that globalization has driven the value out of prog
Retro computers (Score:2)
Then there's also the popularity of retro computers and consoles. There is an increasing number of indie/amateur developers developing for these machines as a hobby.
During the last few months I have been uploading my Z80 assembly code to GitHub myself (a game for MSX computers), and many other developers are doing the same.
Toothbrush? Coffee Machine? (Score:3)
My 300Euro coffee machine runs no code at all.
Neither does my plastic tooth brush.
And by the way: Assembly is not a language. 68k Assembly might be one assembly language. x86 another one. Both have not much in common.
It's not rocket science! (Score:4, Interesting)
Perhaps THOBE is mistaking the fact the NASA put up the full assembly code for the Apollo 11 guidance computer on Github and the interest in that (6000+ stars) for a revival of the language instead of a historical artefact.
Check it out here and don't forget to start it, together we can confuse THOBE and make Assembly the #1 language of the world again! ;-)
https://github.com/chrislgarry... [github.com]
Assembler is good for certain things (Score:4, Interesting)
First of all, many, if not most, computers run software so trivial on microcomputers so small, installing a compiler for them would just be _way_ more effort than to just code to program in C. Typical examples are the microcontrollers in electric toothbrushes or other smaller embedded systems. It's hard to get your software running on a 4 bit microcontroller as modern C makes assumptions like having your memory addressible at a byte level.
Then there is another, in my opinion more important, point. Assembler is a great teaching aid. It shows you what the computer actually does. Understanding things like pointers is trivial in Assembler so you can learn a lot from it. Also in Assembler every control structure hurts, as you need to keep track of it yourself. This nudges you towards writing simpler code, away from thousands of nested if statements and functions with hundreds of lines. Those are desirable traits in all programming languages.
No language is suitable for everything, but most languages have at least one are where they are really useful.
Re: (Score:3)
If you want speed, assembly is the ONLY option.
But virtually all of the optimization happens in virtually none of the code, I always forget the percentages but they are probably made up anyway. You will need some ASM. I think it's more credible that more people are writing some ASM for some parts of some projects. It's not unreasonable to imagine that the ongoing proliferation of embedded doodads would spur that on, but it's a stretch to imagine that it's for devices for which there is nothing but an assembler.
Re:Surprise? Why? (Score:5, Insightful)
There's more than one reason to want optimization. There's optimizing for speed in a full algorithm, in which case assembler isn't that important. But optimizing for speed in localized locations can be very important. Ie, the faster your interrupt handlers are the better I/O throughput you can get, or faster context switches, etc. If you're programming on a DSP for instance, you almost always want the best speed and that often means assembler or assembler wrapped inside of macros or special directives. There's also optimization for size, and occasionally assembler helps there as well to cram in as much as you can in the limited space.
And of course you need to *know* assembler even if you don't write it. It's how you decode core dumps, figure out what your code is doing, and lets you treat the machine as more than a black box (I've seen people with efficient algorithms that weren't so fast because they didn't understand what was fast or slow under the hood).
Re: Surprise? Why? (Score:5, Insightful)
People suck at macro optimizations in assembly. If your assembly program is more than 25 instructions, you're probably not going to do a better job than a compiler.
If you're writing intel code you'll probably see better speedup using c++17 parallel policies or some other parallelization framework, but sometimes it is necessary to optimize small segments of code. Premature optimization is the root of all evil and effective use of templates and metaprogramming can go a long way without much effort. Embedded devices should be treated to same way. Write a high level implementation in the highest level language available to you and hand optimize only when necessary.
I've compared c++ stl implementation of algorithms to c implementations and my c++ almost always runs faster with significantly less code. Small programs that calculate trivial results are always faster in low level languages, but real programs need complicated structures and its almost always infeasible to hand optimize those effectively.
Re: (Score:2)
Re: (Score:2)
There are a couple of reasons to optimize early.
Design of your program may change depending on maximum capability. It's better to change a design earlier in development.
Faster run times can improve testing and debug cycles.
Re: (Score:2)
And there are more good reasons to not do it except in special cases. The primary one is that it makes coding much more expensive, mostly via increased effort in debugging.
Re: (Score:3)
Basically the code and vars won't fit in the chip I have at the moment without finding weird ways to save space. So there are times when changing something in assembler can save a couple hundred bytes. There's also parts of the code even more constrained in size, like a bootloader that has to fit in 4k, so optimizing there is worth it.
Re: (Score:2, Informative)
Take a look at OpenSSL some day cowboy.
Generally the asm paths are at least 3x the speed of the code the best compilers can generate.
When the speed up for using asm on Itanium was 5x was when I realized it was doomed. The compilers were further from human performance than on the older architecture and that wasn't going to improve.
C++? In my 8-bit MCU? Get out of here (Score:2)
What you say may be true of x86, x86-64, ARMv4-7, and AArch64, which get the most attention from compiler authors. On an 8-bit microcontroller, assembly tuned specifically for a particular ISA's available addressing modes can handily beat C++. Some ISAs, such as 6502, prefer a set of parallel arrays instead of an array of structures.
Few actually understand how to do assembly (Score:2)
People suck at macro optimizations in assembly. If your assembly program is more than 25 instructions, you're probably not going to do a better job than a compiler.
Good assembly language programmers are not trying to out-optimize the compiler at instruction scheduling. Good assembly language programmers are leveraging information that can not be communicated to the compiler.
Re: (Score:3)
One benefit of hard resetting a stack, register or even a variable after each use is that it is a step towards making your code more deterministic, by setting it to a known safe state.
For some of the driver code I develop, the ability to do that in a strict manner, without a compiler overriding my design, is why I use some assembler.
Re:Surprise? Why? (Score:4, Informative)
Re:Surprise? Why? (Score:5, Insightful)
If you do not know assembly, you cannot be a really good coder and you cannot even understand how common attacks on code work these days or why some things run much slower than others. That said, actually coding in assembly is something you only do when there are very good reasons to and mostly as assembly embedded in C.
Re: (Score:2)
Re: (Score:2)
I fully agree that writing assembler without a very good reason is not a good idea today.
Re: (Score:3)
>> If you do not know assembly, you cannot be a really good coder
> That is bollocks.
Only shitty programmers are clueless about assembly, which in turn implies they lack an understanding of memory access patterns.
Hint, try *reading*: Pitfalls of Object Oriented Programming [cat-v.org]
Even Bjarne Stroustrup, the designer of C++, until 2012 was completely cluess _why_ doubly Linked Lists were so slow compared to Arrays [youtube.com]
HINT: Managing the L1 Cache usage is critical for performance sensitive code.
Programmers concern
C/C++ can be written in arch specific way (Score:2)
In the day of viable superoptimizers or superoptimizer-generated peephole optimizers and viable evolutionary/exploratory/search-based compilers, you should need to know assembly even less than ever before. Remember, the machine can try out new things both faster than you and cheaper than you.
Contrary to popular myth C/C++ code can be written in ways that favor one architecture over another. One reason to understand the architecture, assembly language, is to write better C/C++ code for your target.
And then there is debugging.
Re: (Score:3)
There was a very good op-ed from the Usenet days which pointed out that an assembly programmer will always beat a high-level-language programmer on most performance metrics because a typical assembly programmer can use a compiler but a typical high-level-language programmer can't use an assembler.
An assembly programmer can use a profiler to work out where the problems are, inspect the output of the compiler, see what's wrong with it, and fix it using assembly. (Today we might include intrinsics as a potenti
Re: (Score:3)
There was a very good op-ed from the Usenet days which pointed out that an assembly programmer will always beat a high-level-language programmer on most performance metrics...
Dozens of posts so far and all missing the central point: in terms of determining popularity, tiobe's methodology is junk. People search when they have questions. Sure, more people have questions if more people are using a given language, but this is trumped by obscurity and steep learning curve. Really, there is little in the technology world more obscure or harder to master than machine level coding. If a language is well structured then you just go straight to the web resources, the many excellent C++ si
cc65 doesn't optimize much (Score:2)
It's not unreasonable to imagine that the ongoing proliferation of embedded doodads would spur that on, but it's a stretch to imagine that it's for devices for which there is nothing but an assembler.
For systems using a 6502 family CPU, there is a C compiler [github.io]. But it doesn't optimize much, and the 6502 architecture isn't well suited for efficient execution of C anyway. That's why even though a few modern-day NES games are written in C, most are written in assembly language.
Re: (Score:3)
Even with a CPU as old as DEC's Alpha back in the late 1990's I was astounded when DEC's C++ compiler produced faster code than I could with basic assembly.
Re:Surprise? Why? (Score:5, Informative)
That hasn't really been true for a long time, unless your hand-written assembly code will reliably outperform a good compiler's generated code.
Hint: It's a reasonably safe bet that it won't, unless you actually are a world-class expert on the subject, such as the people who write those compilers.
Modern CPUs are not the chips your grandpa programmed. They are full of caches, pipelines, predictive execution, parallel operations, and numerous other confounding factors that mean what you think will run fast and what will actually run fast may be two wildly different things, even in apparently simple cases.
Whole teams of very smart people spend years reading and understanding thousands of pages of CPU specs so they can write compilers that analyse and optimize code at the speed of those modern CPUs to generate efficient machine code from it. Even if you can beat them on implementing one simple algorithm in isolation because you can spot something the compiler missed, modern high level languages encode so much more programmer intent than raw assembly that you might still lose out overall because you're disrupting larger-scale optimisations.
Re:Surprise? Why? (Score:5, Informative)
I write compilers for a living, and I came in to say something much like the above.
I have direct experience recoding moderate sized C++ functions in hand-coded assembly. I have been able to beat the C++ compiler, but... not easily, and not without major elbow grease and lots of my time. It's most often not an easy thing to do, because the compiler has sophisticated scheduling and optimization algorithms, and because of the hardware complexity the parent post is talking about. Most programmers weaned on Java don't quite grasp the performance complexity that exists in modern CPUs.
Does it ever make sense to write asm directly? Once in a while, yes, but in the vast majority of cases, optimization time is better spent at the C++ level improving the time complexity of algorithms that dominate the problem space, or perhaps recoding Java into C++. Outside of very specialized and rare circumstances, I don't find reasons to optimize below the C++ level.
There are highly constrained devices where directly coding asm is the way to go, but fewer and fewer all the time.
Re:Surprise? Why? (Score:5, Interesting)
There are a lot of processors out there that aren't complicated. On an 8 bit microcontroller with an instruction set size of only a few dozen, it's not hard to beat compiled code.
Re:Surprise? Why? (Score:5, Interesting)
Counter-intuitive as it may seem at first, the smaller your instruction set, the higher the chance that the compiler is actually better at optimizing than you are, unless you have a LOT of experience writing and optimizing assembler code. Mostly because the smaller the set, the longer the code gets and the more you have to take into account certain side effects from instructions. I spent quite a few hours puzzling why the compiler would completely rearrange the instructions only to notice that it gained a bit of an advantage from creative pipeline restructuring and carefully manipulating certain jumps.
The only area where humans outperform compilers reliably is conditional jumps. Because humans can usually more readily tell from the intended program flow which branch is more likely to be executed and can optimize the programs in that way. Hand that information to the compiler and I hold any bet that it will outperform you any day.
Re: (Score:2)
the smaller your instruction set, the higher the chance that the compiler is actually better at optimizing than you are
Unless the authors of the only compiler for your ISA maintain it as a hobby and aren't interested enough in optimization to quit their day jobs. Case in point: cc65.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If you are on an 8 Bit MCU, speed is not that critical, or you would use a larger and faster MCU.
Larger MCU for existing devices? (Score:2)
If you are on an 8 Bit MCU, speed is not that critical, or you would use a larger and faster MCU.
When you want to add a new feature to hundreds of thousands or even millions of devices in the field, have fun recalling them to install "a larger and faster MCU."
Re: (Score:2)
Is that the CPU and instruction set we are all using, or is that some specious reference to a bygone era with no actual current value?
Re: (Score:2)
I write compilers for a living, and I came in to say something much like the above.
I apologise in advance for the following rant. It may not be fair to direct it at you personally, but I'm going to do it anyway.
There is a trend happening in modern C-family compilers where they have decided to go full language-lawyer on aliasing rules. It's getting much, much easier to write code which looks sane and has worked for 20 years, but compiles to code which subtly does what you don't expect on the most recent compilers.
Now this isn't entirely your fault, because C-family language standards are s
Re:Surprise? Why? (Score:5, Interesting)
They are full of caches, pipelines, predictive execution, parallel operations, and numerous other confounding factors
You are using all the same arguments C/C++ programmers used in 1995 but if the discussions wasnt about assembly language but instead the discussion was a comparison of compilers from 1995 with compilers from 2015 you would be telling us how terrible those 1995 compilers were at optimization even then.
..and if you are "confounded" by caches, pipelines, superscaler techniques, and so on ("cause surprise or confusion in (someone), especially by acting against their expectations.") then its because you are ignorant of the architecture. Your ignorance doesnt define reality.
..and notice how its now 10% faster... or 20% faster... there is a range because it depends which gcc compiler version is used (older versions produce better code.) If gcc has such a large variance in performance, if newer versions are slower, then what are we to think of the veracity of your claims? I'll tell you what: they arent veracious claims. They are wishful thinking.
The fact is that it doesnt require an expert to beat a compiler at optimization. The fact is that your idea of an "average assembly language programmer" is actually a terrible assembly language programmer. When you dont consider someone that learned C/C++ a month ago an average C/C++ programmer, why do you then consider someone thats literally never actually taken assembly serious as the benchmark average?
Recently a programmer undertook the task of converting the strongest open source chess engine (stockfish) to 80x86 assembly language. He still has done no optimization. He has literally just done a straight simple conversion and its already 10%...20% faster and is now easily beating the C++ compiler version in tournaments.
Re: (Score:2, Flamebait)
Spoken like a twat that hasn't got any metrics to back up his rhetoric.
Re: (Score:2)
Spoken like a twat that hasn't got any metrics to back up his rhetoric.
You are right. I dont have metrics. I just have binaries.
C++ version of stockfish [abrok.eu]
80x86 asm version of stockfish [github.com]
One of these is faster. I'll let you decide what "metric" to use.
Re: (Score:3)
http://spcc.beepworld.de/ [beepworld.de]
Note how he included a june build of asmfish, and that asmfish is leading even against july builds of stockfish.
Which "metric" should we use?
Nodes per second? asmfish is faster than stockfish.
Time to depth? asmfish is better than stockfish.
Playing strength? asmfish is better than stockfish.
I wonder what metric this guy is going to want to use that retains his wishful thinking of C++ supremacy. M
Re: (Score:2)
GCC has never been a very useful benchmark for compiler performance in my experience. Even a decade ago, when I used to work on a lot of very performance-focused mathematical code that was compiled on many different platforms, Visual C++ would generate code that often ran twice as fast as anything g++ would produce on Windows, and if you looked at what the Intel C++ compiler could do it was much better still.
It's also worth remembering that C++ is still quite low level on the programming language spectrum,
Re: (Score:2)
Re: (Score:2)
In embedded sometimes very small processors with simple instruction sets are used to save power and money.
Sometimes, yes. As you say, in addition to assembly programming being simpler on those platforms, compilers are often much less sophisticated in their optimisations as well, so going with assembly is a double-win.
That said, in an era when you can build a complete Raspberry Pi with a decent ARM chip for a few dollars and when mainstream CPUs are a lot more power-efficient than they were even just a few years ago, using very low-end CPUs is a lot less attractive than it used to be even in the embedded space.
Re: (Score:2)
I used to write assembler. But that was in the days of very limited machine memory, when saving a couple of bytes would matter. It was also in a day when compilers put out relatively inefficient code. Programming, say, I/O, at the assembly level would likely produce code orders of magnitude faster than compiled code that used repeated calls to I/O libraries.
But today there's plenty of memory in most computers, and compilers are really good. So I only see two reasons to write assembler. One is to deal with s
Re: (Score:2)
Re: (Score:2)
No. Yes. No. Uh... that really depends.
On a modern desktop CPU, no chance. gcc optimizes in ways you wouldn't even dream of. Even Visual C++ produces decently optimized code. Usually, writing ASM yourself you can't come close to the optimization level that modern compilers achieve.
Except Atmel's very own compiler. That's the maybe WORST kind of rubbish I have ever seen. Here you can actually gain a LOT of performance and code size by hand craftin ASM code. Which says something considering that, unlike deskt
Re: (Score:2)
Re: (Score:2)
Bullshit. A good C-compiler will do as well or better in most cases. For the rare case where it does not, embed assembly for the critical parts. You may also need embedded assembly in drivers, where hardware has to be accessed just right in order to work or work fast.
Re: (Score:2)
No it's not. C is also an option, given a good optimising compiler.
Horsecrap (Score:5, Informative)
You may be right for some VERY small and trivial applications, but sometime in the early 90's optimizing C compilers FAR outstripped hand-coded assembly for any larger project. These days it isn't even a contest. A good optimizing compiler like the Intel C/C++ compiler can crank out code that is anywhere from 3 to 10 times faster than what you can do by hand. I should know, I did PLENTY of Assembly, and worked with some LARGE assembly-language applications back in the 80's. ALL of them were totally rewritten in C before 1995, and I'm talking about RTOS kernels and stuff, things where one clock cycle matters. There may be some few very specific 'inner loop' interrupt handling logic and such that is still written in assembler, mostly because that sort of code is idiosyncratic and can't really be safely optimized, but we're talking a very few lines of code, maybe 500 out of 500k SLOC.
I can buy the idea that there are 'IoC' things out there with extremely minimal processing power, basically little 8 bit devices with a few K bytes of RAM and Khz CPU clocks that you really CANNOT code in an HLL. Of course the amount of code that you write for that thing is obviously also extremely minimal. We're talking "blast this fixed length 802.11 frame out there every 2 seconds with these 12 bytes holding the RAW bit values from the ADC and the 3 discretes to a broadcast address" kind of thing.
Re: (Score:2)
Re: Horsecrap (Score:2)
Re: (Score:2)
Re: (Score:2)
I strongly suspect the job ads counted are for "Assembler and C" or the like, never only assembler.
Re: (Score:2)
seen almost exactly zero evidence that this "trend" is real.
Are you looking at programming jobs or electrical engineering embedded development jobs? This is kinda the thing that an EE does almost as an afterthought.
Re: (Score:3)
I wanna see a human beat any modern-day compiler to optimizations.
asmfish [github.com]
10% to 20% faster than the C++ version.
The authors of the c++ version have attributed the speed gains to better register usage. The author of this asm version says he hasnt actually started optimizing yet.
You C++ programmers are delusional.
The preferred form for making modifications (Score:2)
I think they're talking about projects whose source code is in assembly language, where a work's "source code" is defined as "the preferred form of the work for making modifications to it" (GPLv2, GPLv3). That is, something like the Pently audio player [github.com] (which uses a preprocessor written in Python but is otherwise in 6502 assembly) or the video games RHDE: Furniture Fight [github.com] and Nova the Squirrel [github.com].
Re: (Score:2)
Fuck FORTH and fuck Reverse Polish Notation.
Re: (Score:2)
01010011 01110100 01110010 01100001 01101001 01100111 01101000 01110100 00100000 01110101 01110000 00100000 01100010 01101001 01101110 01100001 01110010 01111001 00100000 01101001 01110011 00100000 01110111 01101000 01100101 01110010 01100101 00100000 01110100 01101000 01100101 00100000 01100001 01100011 01110100 01101001 01101111 01101110 00100000 01101001 01110011 00101110 00100000 01000101 01110110 01100101 01110010 01111001 01110100 01101000 01101001 01101110 01100111 00100000 01100101 01101100 01110011