Does anyone even know what MASM is anymore ?

[ninaholic37]

The Microsoft Macro Assembler (MASM) is an x86 assembler that uses the Intel syntax for MS-DOS and Microsoft Windows.

Two benefits of using ASM I can think of:

- You can save and pull values directly from the CPU registers which is faster than going to RAM (reducing cycles/time)

- Gives you finer control than a high-level language because every instruction is directly translated into the Opcodes used in the executable

 

[pm]

I spend a fair amount of time writing assembly code. In fact the two types of code that I write are either assembly or some scripting language (TCL, Perl or Python). I was under the impression that for very important performance applications in games and especially in HPC (high performance computing) applications they use things like pre-optimized assembly primatives.. like these: https://software.intel.com/en-us/intel-ipp

More recently I've been looking at wireless basebands and those all seem to be hand-coded in assembly. (or if they are compiled, then their compiler produces comments)

I remember writing code in assembly back on my commodore 64 in the 80's.. but we didn't have a lot of memory back then and compilers sucked at producing dense code. I even remember writing self-modifying code to save memory (go back and have later code change earlier code and then reloop through). It was neat... but a huge time sink.

On a more recent note, I will say that based on personal experience, things like memory management, and multi-threading are super confusing to write in assembly.. particularly optimized multi-threaded code... it's not impossible, but it is hard and requires a bunch of trips through a performance monitor. It's one thing to write some sort of in-line code to do calculations which is relatively straightforward, but once you want to split it off into threads, it all starts to get beyond my ability to efficiently keep track of it all and I end up iterating over and over and watching the performance monitors and then tweaking things and then not even understanding why a certain tweak helped so much. All of which takes time and only makes sense when you need something to run super fast... which is not that common a requirement in these days of >4GHz CPU's with 4 cores that are all hyperthreaded. Why go through the pain of tweaking something for speed (and losing portability across ISA's, or even various CPUs of the same ISA) if it's all going to run fast enough anyway in most applications?

 

[MisterMac]

It occured to me that now programming is mainstream (And programming apparently includes webscripting for most people) - aren't Assembly programmers, hardware and circuit logic designers like ...rockstars?

Finding people that have passion and can understand the complex system rules all the way thru must be so rare.

Must make pretty decent dough?

 

[Fjodor2001]

It occured to me that now programming is mainstream (And programming apparently includes webscripting for most people) - aren't Assembly programmers, hardware and circuit logic designers like ...rockstars?

Finding people that have passion and can understand the complex system rules all the way thru must be so rare.

Must make pretty decent dough?

Not necessarily, because the demand for such talents is not that big. Most programs are not written in assembler these days.

 

[Fjodor2001]

Some comments from a SW developer perspective:

* Assembler still has it's place in some cases. E.g. there are still parts of OS kernel code that has to be written in assembler, since there is stuff that is CPU ISA dependent.

* Assembler can speed up SW, but generally it's not worth the effort. Typically you only write some sections of the OS and common core libraries that will be used often and by a lot of code in assembler, since that mean lots of other code written in other languages will benefit from it too.

* Writing large programs in assembler is a hassle, since it's much harder to create a nice design. So you might actually create design flaws that end up making the SW slower compared to writing the code in e.g. C/C++/C#. Also, the chance of introducing bugs is far greater. And the amount of "functionality" that a programmer can code per time unit is of course much less, i.e. the productivity is far less.

Having said that, I do find that writing code in assembler has a certain charm to it. Because you're actually down to the "bare metal" and have exact control of what is happening down to every last CPU instruction.

 

[DrMrLordX]

There is also the issue of portability. But, what you say is essentially correct. I will say that anyone who can really code proficiently in ASM will always be able to find work somewhere, be it x86, ARM, or even other ISAs.

In "the real world", you sometimes see stuff like 7zip which is a hybrid C/C++ project with some ASM for speed where it counts. Take a look at the source, you'll see what I mean.

 

[VirtualLarry]

Not messing around with assembler.

I'll go so far to say: thinking that programming in assembler will speed up your programs, is a sign that someone is a true amateur.

Or that someone has too much "faith" in their compilier.

Look at some of the assembly-language (primarily) "demos" for PC, back in the 386/486/early Pentium days. Back before GPUs were even a thing. Very impressive stuff.

 

[Ajay]

Assembly is still used in various types of firmware applications. I used to do development for high speed networking switches/routers and we had some critical path components written in i960 & PPC 750 asm. Given the advances in ASICs - I doubt there is any asm in these type of devices anymore.

But with less powerful controllers, there is still room for some optimization (even though compiler's have gotten much better, especially if you use the right flags for the application at hand). Also, I find assembly a critical skill for debugging. If you have a good debugger, you can even test fixes on the fly by jumping out to free memory, write up the fix and then jump back to a point after the broken code.

Since the last bunch of Applications I developed were mostly in Java or FLEX; I've gotten away from assembly in a way that makes me a bit sad.

 

[Fjodor2001]

Look at some of the assembly-language (primarily) "demos" for PC, back in the 386/486/early Pentium days. Back before GPUs were even a thing. Very impressive stuff.

Yes, I do remember the "demo" days. Then you would take control of the computer from the very first CPU instruction, and all that executed was the exact assembly instructions you had programmed yourself. No OS or anything.

Back in those days a small crew of 1 coder, 1 gfx artist, and 1 sound guy could develop a game on their own.

Today your code is usually just a small brick in the Chinese Wall. In one way it's fascinating, since the scope of the SW is so huge. The Linux Kernel alone is ~15 million lines of code (although only some parts is activated depending on what config is used). But in the old days, you felt you had more control over everything.

I guess it's the same for HW guys developing chips. The team that designed the 8086 could probably have a pretty good idea of most parts of the CPU. But for the team that designed Haswell, I imagine most engineers only had detailed knowledge of their specific part. That being some ALU block or similar.

 

[jhu]

Yes, I do remember the "demo" days. Then you would take control of the computer from the very first CPU instruction, and all that executed was the exact assembly instructions you had programmed yourself. No OS or anything.

Back in those days a small crew of 1 coder, 1 gfx artist, and 1 sound guy could develop a game on their own.

Today your code is usually just a small brick in the Chinese Wall. In one way it's fascinating, since the scope of the SW is so huge. The Linux Kernel alone is ~15 million lines of code (although only some parts is activated depending on what config is used). But in the old days, you felt you had more control over everything.

I guess it's the same for HW guys developing chips. The team that designed the 8086 could probably have a pretty good idea of most parts of the CPU. But for the team that designed Haswell, I imagine most engineers only had detailed knowledge of their specific part. That being some ALU block or similar.

No kidding. Remember when two slack-jawed yokels from Ohio developed powered flight? Now we have the A380 and the 787 requiring teams of engineers and decades of development. Why can't we just get back to the basics of powered flight?

 

[PhIlLy ChEeSe]

I've been wading through some of the Forums here and it strikes me that Games software houses are, (and have been for some time by the look of it), churning out top end games, (I don't "game" btw), which require ridiculously expensive high-spec. hardware to run them properly. I suspect that somebody, somewhere is scrimping on assembler. Someone, somewhere, is, in as many words, saying, ."..that routine would take far too long to debug in assembler, so when we release it - ....recommended hardware specs. will be 73.8ghz 100 core cpu, 112,500gb's RAM, 142 SLI / Ti graphics card (each with 50gb of DDR55 RAM), and advice that before firing up the game, one must notify one's local power generating company that a significant extra load will be coming online within the next few minutes - so you may want to cut in a couple extra mains power generating stations

During the 80's/90's John Campbell, who programmed exclusively in assembler, marketed "Masterfile PC" (a database prog.) which could sort thousands of records in just seconds flat on an IBM PC compatible | 8086 - 8mhz cpu | 640kb RAM | two 5 1/4" floppy drives, and no hard disk !

So there we are, machine code routines are obviously being called during gameplay but, one wonders if the software house game writers even know what they are ?

regards, Richard

You don't game BUT, lol another paid spammer! Does Anantech need to make the forums look busy so the sponsor dollars keep rolling in?
http://forums.anandtech.com/member.php?u=359221

I smell a sinking ship! D:

 

[Gryz]

Or that someone has too much "faith" in their compilier.

It's a very good attitude, and practical attitude, to have faith in your compiler. Especially if it comes from Intel, or is GCC. I doubt many people can improve the generated assembler code. And even if they can, it's a waste of their time.

The biggest mistake when trying to optimize software, is to start optimizing before you know how your code behaves.

You start with a good design. Like I said before: what algorithms will you use ? What is the complexity of those algorithms ? What datastructures will you use ? Will you do a lot of lookups in your data ? Or a lot of inserts ? How long-lived is your data ? (You don't want to constantly allocate and then free memory). Etc, etc. Then you start writing code. Test it, debug it.

Only then, when your code is running, the big bugs are out, most of the functionality is in, then you can start thinking about optimization.

You run your code and profile it. Where is your program spending its time ? What functions are being called all the time. Only after you know this, then you know where you can start optimizing. You can see if you can improve the relevant algorithms and data structures even more. And maybe, just maybe, there are a few chunks of code that could be optimized by writing small assembler routines.

Starting your design by saying: "we're gonna write this in assembler, because we need speed" is madness.

 

[Exophase]

It's a very good attitude, and practical attitude, to have faith in your compiler. Especially if it comes from Intel, or is GCC. I doubt many people can improve the generated assembler code. And even if they can, it's a waste of their time.

Assembly code isn't always a waste of time.

Looking at one particular profile, the app I have on Android (Nintendo DS emulator) is spending about 65% of its runtime in assembly or assembly-like code for an ARMv7a NEON build. This corresponds to three categories of code:

1) Machine code generated at runtime to emulate the CPUs
2) Stub functions that the generated code interfaces
3) 2D, 3D, geometry, and sound emulation using (for the most part) NEON SIMD routines

The non-assembly alternative to #1 would definitely mean much worse performance. At least some of #2 needs to be assembly to properly interface #1, and much performance would be lost if more was passed over to C functions, largely due to efficiency waste in matching ABIs up. #3 I know empirically makes the functions significantly faster most of the time, vs the compiler's auto-vectorization. And there are still more functions where moving to assembly would probably make a significant difference.

Here the app's utility basically lives or dies on its performance, and why it can exist at all vs free alternatives. Even on devices/with games where it can handle running it full speed, more efficient means better battery life and less heat.

The biggest mistake when trying to optimize software, is to start optimizing before you know how your code behaves

.

You start with a good design. Like I said before: what algorithms will you use ? What is the complexity of those algorithms ? What datastructures will you use ? Will you do a lot of lookups in your data ? Or a lot of inserts ? How long-lived is your data ? (You don't want to constantly allocate and then free memory). Etc, etc. Then you start writing code. Test it, debug it.

Only then, when your code is running, the big bugs are out, most of the functionality is in, then you can start thinking about optimization.

This is commonly stated, and often it's good advice, but the thing is - and I'm speaking from a lot of experience on this - for some classes of programs if you don't put a lot of thought into getting an efficient architecture done upfront you're going to end up with something that can't be optimized much. And will have to rewrite a lot of it. Sometimes you're better off doing this anyway, where it's better to have something that works earlier even if you know you'll rewrite it later. But other times this can add a lot of overhead to the development cycle.

Of course, when I say optimization I mean something a lot broader than converting functions into assembly or micro-optimizations. You list a lot of things that I would consider performance oriented. A lot of times when people are told "don't optimize prematurely", they don't hear "start with a smart performance-conscious design and don't think about the lowest level details yet", they hear "do whatever's easiest and cleanest without any thought to performance and worry about fixing it later." So we're probably not that far off from each other here. I would just say that there are times when you can actually have good reason to know in advance that you'll have to worry about details that are somewhat lower level than the sort of things you listed.

But yes, "people should write everything in assembly, it's faster!" is totally off the wall.

One other thing I'd like to add about assembly coding: it's not strictly limited to just replacing the compiler. When you write the assembly you extend the feedback loop. Personally examining constraints that are only clear at the assembly level can lead you to restructure your higher level algorithms in a way that becomes more efficient. The compiler works strictly one way. Oh, you can look at the compiler output, but it's a) much more obfuscated/weird/hard to understand than hand written assembly code and b) it's much harder to influence and control what kind of code the compiler generates.

 

[zir_blazer]

As Zir blazer says, you might gain a 10% speedup. If you're lucky.

10% (Actually 15%) was what John Carmack said about an hypothetical 100% ASM Doom engine. Here is the quote:

Although it has often been theorized that Id uses a lot of assembly language in its development, the main language used is ANSI C. "Assembly language is almost dead," declares Carmack. "Doom has only two assembler routines: one to vertically stretch a column and the other to horizontally texture-map a row. Everything else is in C."

If all of Doom was written in assembler and the programmer could manage the overhead correctly, Carmack theorizes it would only make the game 15% faster. And, although the main raycasting trace in Wolfenstein was written in assembly language, Carmack says he could write Wolfenstein faster in C because of today's better algorithm technology.

...BUT, we're talking about the DOS days, when you were working quite close to the Hardware. Lets not get starter about the abstraction layer upon layer upon layer that you have to deal with now for Hardware access with both Drivers and APIs, everything adding their share to the overhead. If someone tried to port a modern game or engine to ASM and bypassing all the API bloat, then say that it is 2-5 times faster, I wouldn't be surprised.
Also, keep in mind that Doom predates the P5 Pentium, which was the first x86 Processor with dual ALUs (The Quake 1 engine was already Pentium-optimized), and there weren't any extra Instruction Set Extensions. Compilers should have evolved to be much more complex than at that time, which many more choices and assumptions that they must make to produce either compatible or faster code. I think that even if overally they are more efficient, the gap should have increased a lot with the drastically increased choices that can be made to achieve something, allowing a good Assembler programmer to optimize by hand things that someone that doesn't understand the Hardware will never be able to, much less a compiler, which doesn't have the flexibility.

It's a very good attitude, and practical attitude, to have faith in your compiler. Especially if it comes from Intel, or is GCC.

I already stated that GCC had its share of compiler-induced bugs, many related to compiling the Linux Kernel. Since compilers are soo complex, it is obviously that eventually they could introduce bugs into perfectly working code (Which was the case with Linux). Can you blindlessly have faith on it?
And the Intel Compiler... wasn't that the compiler that specifically looked for the "GenuineIntel" string using CPUID, and if was something else, it decided to not use faster SSE codepaths thus killing AMD Processors performance by forcing them to use legacy x87? Yup, I have faith in that one too.

Looking at one particular profile, the app I have on Android (Nintendo DS emulator) is spending about 65% of its runtime in assembly or assembly-like code for an ARMv7a NEON build.

Oh, ASM for console emulators is absolutely wonderful, and its one, if not, THE reason why I love it soo much. ZSNES was made in ASM and was important during the 90's, because it was extremely fast at a time where you couldn't simply throw a faster Processor to solve the problem. Basically, ZSNES under DOS on a Pentium MMX 166 MHz ran in circles against SNES9x in WXP with a K6-II 500 MHz. Then there was NeoRageX, a Neo Geo emulator, also made in ASM. It could play in my humble K6-II games in real time, which were ridiculous choppy in MAME. Even through accuracy-obsessed folks usually claims that they were rather hacky and messy, it was wonderful to see such performance, they made my computer feel fast, while everything else made me remember that it was an outdated piece of junk, and that because my family had an empty wallet, I had to deal with it.
Finally, no$gba, which was the first emulator capable of running commercial Nintendo DS games, made in ASM. The guy that made it is an ASM genius, and has also several legacy console emulators in ASM, too. Performance wise, they stomp everything else I tried. In all 3 cases, the difference against other emulators was rather dramatic.

 

[Exophase]

Oh, ASM for console emulators is absolutely wonderful, and its one, if not, THE reason why I love it soo much. ZSNES was made in ASM and was important during the 90's, because it was extremely fast at a time where you couldn't simply throw a faster Processor to solve the problem. Basically, ZSNES under DOS on a Pentium MMX 166 MHz ran in circles against SNES9x in WXP with a K6-II 500 MHz. Then there was NeoRageX, a Neo Geo emulator, also made in ASM. It could play in my humble K6-II games in real time, which were ridiculous choppy in MAME. Even through accuracy-obsessed folks usually claims that they were rather hacky and messy, it was wonderful to see such performance, they made my computer feel fast, while everything else made me remember that it was an outdated piece of junk, and that because my family had an empty wallet, I had to deal with it.
Finally, no$gba, which was the first emulator capable of running commercial Nintendo DS games, made in ASM. The guy that made it is an ASM genius, and has also several legacy console emulators in ASM, too. Performance wise, they stomp everything else I tried. In all 3 cases, the difference against other emulators was rather dramatic.

I should make it very clear though that despite > 65% of the runtime being in assembly (or runtime generated code) in that profile, only 20.1% of the lines of code for this build is ARM assembly. The rest is C. And all of the functions listed in the third category (for 2D, 3D, geometry, and sound emulation) that have ASM versions also have a C equivalent that was written first and is used on other architectures. Note that assembly by its nature requires more lines of code to get similar amounts of work done, especially since I use the C preprocessor for things like register allocation and have a lot of extra lines for defining and undefining.

While some of the code would benefit from being in assembly, particularly some routines that can be tightly coupled with the generated code, most of it is fine as C and wouldn't change performance in a meaningful way if converted.

The same could probably be said for emulators that are written entirely in assembly.

 

[Cogman]

For my day job I've done a lot of performance tuning. 2 things stand out to me.

1. If there is ANY network/disk/database IO, that is where your performance problem is at.
2. Most performance problems are caused by haste/neglect/incompetence/whatever (every programmer does it), Very VERY few are caused by the language.

The main reason, IMO, that rewriting methods in assembly sometimes improves performance is because when rewriting in assembly you are more prone to redesign the algorithm underlying the method. You could, in many cases, re translate the assembly back to c/C++/whatever and probably reap equivalent performance boosts.

Games aren't big, bloated, slow, etc because they aren't being written in assembly. They are big, bloated, and slow because management doesn't care about performance, size, or anything like that. They care about shipping an ok product as fast as possible. The only way they will care about performance or size is if the game won't run for more than 10 minutes on their minimally speced machine.

 

[Ajay]

For my day job I've done a lot of performance tuning. 2 things stand out to me.

1. If there is ANY network/disk/database IO, that is where your performance problem is at.
2. Most performance problems are caused by haste/neglect/incompetence/whatever (every programmer does it), Very VERY few are caused by the language.

The main reason, IMO, that rewriting methods in assembly sometimes improves performance is because when rewriting in assembly you are more prone to redesign the algorithm underlying the method. You could, in many cases, re translate the assembly back to c/C++/whatever and probably reap equivalent performance boosts.

Games aren't big, bloated, slow, etc because they aren't being written in assembly. They are big, bloated, and slow because management doesn't care about performance, size, or anything like that. They care about shipping an ok product as fast as possible. The only way they will care about performance or size is if the game won't run for more than 10 minutes on their minimally speced machine.

Good points. I was trying to remember when I ever wrote lazy code, and the only times I've done that is when I didn't need any extra performance. Often I was using a language feature (or API) that I might otherwise avoid because it easier to let the compiler figure it out for me rather than doing any hard work on the algorithm. Given that I learned to program with limited RAM and CPU performance - I've always been disciplined about about writing that way (and working in firmware just reinforced that ethic). As such, I've never gotten any starts for the most LOC written per month or anything like that - but I write very solid code. I think if I worked for a gaming company - I'd freak out, and possibly get fired!

 

[Fox5]

It occured to me that now programming is mainstream (And programming apparently includes webscripting for most people) - aren't Assembly programmers, hardware and circuit logic designers like ...rockstars?

Finding people that have passion and can understand the complex system rules all the way thru must be so rare.

Must make pretty decent dough?

If you can find a job looking for those skills, the pay is definitely above par, but it's unlikely to be super rich. However, they really only want people who are really good at those roles, so only true rockstars will get those jobs. The gap between employed Java programmers can probably be 100x, but the gap between employer assembly programmers is probably much smaller, the ones who aren't rock stars will have to program something else or become obsolete.

 

[Fox5]

I wrote something in assembly once, and then wrote comparable code in C using GCC optimizing for size. My unoptimized assembly was about half the size, and less than that once I started optimizing out things and not following proper calling conventions. I didn't do a speed comparison because it didn't matter (and probably was io bound anyway).

 

[Gryz]

Games aren't big, bloated, slow, etc because they aren't being written in assembly. They are big, bloated, and slow because management doesn't care about performance, size, or anything like that.

Games are big because they contain a lot of graphics.

A modern game like GTA5 is 60 GB on disk. The 3 executables are 10, 20 and 50 MegabBytes large. The dlls are 20 MB total. So the (compiled) code of that game is less than 0.2% of the total diskspace.

A while ago I installed a bunch of ebooks on my Dad's tablet. He was afraid they would fill all his storage on the tablet. It seems people have no idea about the difference in size between film and a plain text file.

A dual layer BR-disk can hold 50GB of data. That's enough for 9 hours of HD-quality film. That's 93MB per minute. A average 250-page book holds ~500k letters.

So 1 second of HD-video is equal to the content of 3 books.

Unless you compress the books. Video is compressed too, after all. Then 1 second of HD-video is equal to 10 books.

Code is similar. A compiled computer program is not that large, compared to what people expect. It's all the libraries and abstraction layers that add up. But then, those are really beneficial. And even then, it's still peanuts compared to a few bitmapped logos embedded in an executable.

 

[Ajay]

Code is similar. A compiled computer program is not that large, compared to what people expect. It's all the libraries and abstraction layers that add up. But then, those are really beneficial. And even then, it's still peanuts compared to a few bitmapped logos embedded in an executable.

It's probably bigger than that if you include game specific engine customizations (not familiar with that game, but I've seen Unreal games with a couple hundred megs of customized Unreal code on top of the game code itself. I wouldn't be surprised if many modern games were at least 500 MB of game code. And these are just games, not mission critical enterprise applications developed over many years.

 

[videogames101]

It occured to me that now programming is mainstream (And programming apparently includes webscripting for most people) - aren't Assembly programmers, hardware and circuit logic designers like ...rockstars?

Finding people that have passion and can understand the complex system rules all the way thru must be so rare.

Must make pretty decent dough?

Hardware engineering is really no more difficult than advanced programming, I think it's just that some of us prefer working with actual circuits. The pay is good, but not as good as you might think (at least for me as a recent grad).

 

[cytg111]

On target I would say

http://www.computerworld.com.au/art...ng-system-written-entirely-assembly-hits-1-0/

 

[Cogman]

Games are big because they contain a lot of graphics.

A modern game like GTA5 is 60 GB on disk. The 3 executables are 10, 20 and 50 MegabBytes large. The dlls are 20 MB total. So the (compiled) code of that game is less than 0.2% of the total diskspace.

A while ago I installed a bunch of ebooks on my Dad's tablet. He was afraid they would fill all his storage on the tablet. It seems people have no idea about the difference in size between film and a plain text file.

A dual layer BR-disk can hold 50GB of data. That's enough for 9 hours of HD-quality film. That's 93MB per minute. A average 250-page book holds ~500k letters.

So 1 second of HD-video is equal to the content of 3 books.

Unless you compress the books. Video is compressed too, after all. Then 1 second of HD-video is equal to 10 books.

Code is similar. A compiled computer program is not that large, compared to what people expect. It's all the libraries and abstraction layers that add up. But then, those are really beneficial. And even then, it's still peanuts compared to a few bitmapped logos embedded in an executable.

To true.

But I would point out a few things.

For a game, the 60gb of resources isn't what matters (not so much at least) when it comes to performance. Rather it is what the internal executable is doing that is far more important. There really isn't a direct correlation to code size and program memory consumption. My point is that games are far less performant and use more memory and resources than they need to because it takes a lot of time and effort to reduce that consumption.

For the 60gb of media data. You're bluray example is actually a pretty good one of the nature of performance and resource utilization. For the same films and movies, netflix uses about 5gb of data with almost no visible loss in quality. Even in the extreme 4k case, netflix is using under 10gb of data.

So what gives? Why are studios using 50gb of data when 10gb is more than enough? Simple, because it is available and they can. They use all 50gb not because they need it, but because it is easy to do and they don't have to worry about tuning their compressing suite. At 50gb of data, almost everything is near lossless. With that much wiggle room, it also gives them the ability to move to things like 60fps video or 4k resolutions without needing a new type of media.

When talking about games we are roughly in the same scenario. They waste TONS of data on stupid things like cutscenes, intro videos, etc. They waste tons of data by not maximally compressing every texture and resource. They waste tons of data by not reusing resources or programmatically generating textures (the resource designers/modelers are more prone to copy a texture then they are to reuse a texture).

Why don't they spend the time to minimize the data needed for the game? Simple, because it takes time, release dates are the most important things to management, and data is seen as being pretty cheap. It isn't because the programmers or the designers are lazy, it is because the business model is one of churning out as much crap as fast as possible with minimal polish.

 

[knutinh]

If you want to make a program run faster, it's a waste of time to look at assembler code. As Zir blazer says, you might gain a 10% speedup. If you're lucky. And if you're really good at assembler and hardware architecture. And then in a few months, when a new CPU is released, your speedup-gain might be completely lost...

Instead of guessing, let us introduce some example figures:

http://shervinemami.info/armAssembly.html

I wrote both an optimized C function and an optimized Assembly function (using NEON SIMD instructions) to shrink an image by 4, and my Assembly code was 30x faster than my best C code! Even the best C compilers are still terrible at using SIMD acceleration, which is a feature that is available on most modern CPUs and can allow code to run between 4 to 50 times faster, and yet is rarely used properly

http://hilbert-space.de/?p=22
grayscale conversion for images

C-version: 15.1 cycles per pixel.
NEON-version: 9.9 cycles per pixel.
Assembler: 2.0 cycles per pixel.

See this for x86:
http://www.agner.org/optimize/

Now, the examples above are surely cherry-picked and hardly representative of broad application suite, but it does indicate that certain tasks can be done a lot faster by going low-level. This also makes me sceptical about benchmarks applied to new hardware. Without knowing how the developers of 7zip or x264 or whatever wrote and compiled their binary, it is hard to extrapolate some performance comparision to other applications or some kind of future performance limit for any given platform.

If your computer is going to do the same, limited task a gazillion times it might be worth time and effort to speed up that task for the particular hardware. Assembly might be needed, but there is a list of other options that should be tried before jumping to assembly. Because assembly takes many man-hours, is error-prone, platform-specific, hard to maintain, etc.

Be sure to know the task that needs to be done, the capabilities of your hardware and estimate how close to the hw bounds your current implementation is. If memory throughput is the bottle-neck, fiddling with micro-optimization is probably not the solution.

-k