I'm just curious if there are any coders here that worked in ASM (MASM, NASM whatever)? It's obvious that the high end applications will need ASM to have a technical edge. This includes: Online: market making, arbitrage Offline: data mining I've also heard of many speed critical programs being developed by well funded teams not using ASM and was wondering why? It can and usually does outperform the best compilers by at least 5 times in various tasks in terms of execution speed. There seems to be a lot of room for improvement there, and I was wondering if I am in fact misguided and ASM is really much more widespread in various trading applications?
I doubt the bottle neck is the code. The speed gained up from coding in assembly over C or C++ is probably inconsequential compared to the network communication overhead and disk writing. So spending that extra time and money on hand optimising the code doesn't provide enough of a pay off. Having said that it is easy enough to embed assembler into a C or C++ function if you really need to, its __asm in visual c++ iirc.
Online: sure, you can optimize inner loops with ASM just like 3D gaming engines but with trading systems greater gains can be had elsewhere e.g. tackling network latency. You can also make use of hardware e.g. FPGA Offline: not an issue.
Wrong millenium. Gaming engines inner loops today run on programmable graphcis cards. Also optimizing looks is realyl hard in assembler since you have superscalar architecture. Intel has a tool out that can push your assembler performance by reordering the commands so they execute in parallel. This stuff is getting terribly complex, with multiple commands executing at the same time IF the cpu can do it (no dependencies, using different registers etc.). Makes little sense to go assembler except for VERY rare occasions. C is nearly as good and a magnitude or two faster in development.
Consider this however. Everyone is colocated, has the top of the line networking, and the fastest SSD disks money can buy. What's left? The code obviously. My assumption is that technical hardware issues are almost always fully resolved and pushed to their limits by all of the players. I'm saying is that i suspect there can be much more gained by optimizing code, and perhaps it's the only "edge" left to have for the HFTs and some arb strats.
Oops, you sure you know what you're talking about? Have you ever tried developing search algos and data mining? There are multiple papers written about those, and just doing research still requires a hefty data centre. Many researchers will rent out some time on the cloud or buy their own data centers. Some of these deep data mining techniques may require days, weeks and even months of running on todays harware to get significant results. Offline data mining is one of the main reasons i became good at assembler and i can tell you my applications are beating those used by some hedge funds at least 2x in terms of speed - meaning you need 2x as little hardware for the same results, and this is a time and cost saving. I can probably improve that even further, but never mind that.
Lack of talent... it's very hard to find good ASM talent since few people know it. It's hard to convert a programmer to ASM, especially newly minted programmers who cut their teeth on OO based languages. Development time is huge... some edges only last for weeks, or days, once detected, can't wast that time debugging assembly. While you can do some great things with ASM on limited hardware, it's easier, cheaper and quicker to just toss more hardware at the problem and pick up a bunch of C programmers.
I agree about the superscalar architecture. Hmm, but think about the tight loops getting live data from whatever network, or based on events from harware, etc. These can have at least a few branching segments and compilers get these wrong. FPU comparison and simple operations for example usually involve initializing the FPU needlessly by the compiler (which is slow, about 20 cycles for example). Lot's of CPU cycles can go down the drain there (or waiting for the FPU). How much faster C is for development also depends a lot on the skill of the coder. I haven't coded in ASM as long as in other languages, but those with several years of experience will produce ASM code in the same amount of time as a C coder would. That's what people say on ASM forums anyway, and many have coded very complex apps in short time to prove it. You can use macros and premade code segments to speed things up when coding, and you still don't have to worry about what the compiler might be messing up. It does require you to pay a bit more attention but after a while it becomes natural and you dont think about it so much.
I think i agree with that. That was one of the points of this thread, to find out how many of ASM people are out there. Might not be that many.
That would be a dumb idea. First you will not outperform a Vectorizing compiler like Intel's Fortran and C++ compiler. All the performance requires compilers that can do auto parallelizing and vectorization. Assembler is not for writing code to be used for HFT etc..