Seemingly, no one uses assembly nowadays other than to develop device drivers, or the very core of OS kernels etc. Anyone has knowledge of it being currently used for other things?
I mean PC-style and bigger hardware, not embedded stuff with teeny tiny processors.
I believe that the Folding@Home parallel computing project uses optimized assembly code for maximum speed.*
* Note: this does not mean assembly is always faster then C/C++.
More or less obviously, assembly programming is needed for compiler back-ends and related technologies like dynamic recompiling CPU simulators.
Assembly language programming is also used with some frequency for video game programming, to take advantage of new CPU features that are not yet well supported by current compilers. However, this is kind of rare, these days, especially since on PC's, there are so many different CPU's to support. I expect this is a bit more common on consoles with uniform hardware, though.
Edit: These days games do most of their calculation in a GPU. Getting the most out of these compute resources is not always possible using just OpenGL or DirectX, and the vendors for these processors provide a host of tools for squeezing more out of their hardware. Although Cuda or OpenCL are well known terms, they are still at a relatively high level of abstraction over the GPU hardware, filling in a role that is very similar to the role of C on typical (Von Neuman) CPU's. A look at the developer pages for these products and you will find dozens of ways to use GPU compute resources optimally, and at every level of abstraction.
I know assembly is used for very heavily code for games. For example, pixel shaders have a really tight instruction budget; to get the effects you want, you pretty much have to code down to the metal.
Someone used assembly for this code golf for changing numbers to words.
The last time I came across assembler was when I used to hack the Quake I source code. All the math libraries (especially anything for dot products) were written in MASM by John Carmack. This stuff was floating-point intensive, and at the time C wasn't as good as expertly hand-crafted ASM for floating operations. Also, since computers were far more CPU-limited, and since Quake used the CPU for rendering, every single operation mattered, so ASM worked best.
I think the most prominent programs where assembler is used are boot-loader.
Boost, being as modern C++ as it is, uses inline assembly for low-level performance-critical bits like atomic shared counters.
Edit: as @TokenMacGuy correctly notes, "performance" is a wrong word here. Boost uses assembly language for things that cannot be accomplished in standard C++ such as atomics (and compiler intrinsics are not available for some reason.)
I wrote IBM 370 assembler back in the day, for a large application (vendor sold product, used by large companies) that collected info from hooks in the operating system. However, I was only doing plain jane programming: screens, reports, etc, in assembler. It ran amazingly fast, but was entirely in assembler. I'm sure it is still running and sold today for prices well above what is typical of software for Windows and Linux platforms.
According to Knuth, studying the efficiency of algorithms. He mentions in his books there is no better way to study how an algorithm works than writing in in assembly.
Sometimes certain features are not implementable in a high level language, and inline assembly is used instead. There is some inline assembly in the C++ library Qt, for example; I believe it's used for part of the object introspection system.
In addition, glibc (the C library for gcc) uses assembly for optimization. IIRC one of the software-based floating-point math implementations has significant chunks written in assembly.
One of the primary reasons for learning assembly, however, is debugging. On a few occasions, I've gotten myself into situations where not knowing assembly would have prevented me from debugging a particularly sticky problem.
If you spend a lot of time looking at the assembly output of your C/C++ source, you'll notice very quickly that most good optimizing compilers make better assembly than even good assembly programmers. Decisions on when to inline a function, how to handle loops, post vs. pre increment (which many compilers decide how to handle for you now) etc. Best of luck outsmarting a compiler that has a large community developing it and a much better ability to manage addresses and definitions than you, under normal circumstances at least.
Even device drivers and OS kernels are typically not written using a lot of assembly. Small performance critical sections of real time programs are where you'll find assembly in today's apps.
It gets even worse when you start talking about RISC assembly which tends to have awesomely effective for optimization instructions like branch and exchange along with dozens of general purpose registers. Most people are not smarter than an optimizing compiler. Those who are are generally writing optimizing compilers.
In C, at the fundamental level, it's pretty easy to see how a set of instructions becomes assembler (if you understand the underlying architecture). But sometimes, assembler can't be beat. Note that it is possible to write crappy, inefficient assembly code as easily as it is to write crappy C code. And assembler is way less maintainable. And it isn't portable anywhere.
And it all depends on the quality of the C compiler you're using. Some do better than others. Most compilers allow you to see the assembler code they generate. If you think you can do better, and the code segment is critical, do it. Otherwise, avoid it. Carefully crafted C can be very close to the metal, given a decent compiler.
Utility functions that the higher level language did not expect to support. An old example is from when I was attempting to get some of the niceties that C and Unix provided while working with Fortran on RSX-11M. I wanted to pass formatting strings around and use the simpler C style. The printf() needed to do some cast like operations. The Fortran did not have this concept so icast() and rcast() were written in assembler. Other functions implemented were move() and clone(). These were not done so much for efficiency as they were extending concepts outside Fortran's mindset.
Speaking from experience, it's heavily used when testing and verifying new processor designs. The instruction set has to be stressed using code that a compiler won't necessarily generate. Rather than writing in some higher level language that may or may not compile to the instructions one wants to check, it's easier to write the assembly by hand.
Just as an anecdote: Roller Coaster Tycoon was written entirely (or almost) in x86 assembly by Chris Sawyer (wikipedia reference).
One of the rate determining code (after whatever is needed dynamic for memory management) in nearly every language is the routine used by the runtime (-library) to move memory. Move(), memcpy etc, as well as primitives like searching for a byte (strchr ) etc.
These quite often written in assembler too, with special dedicated code to exploit alignment.