I did not mean that he had to build it, just that CL is not the fastest LISP dialect out there. You need to sacrifice a few features when looking for stupid levels of speed. Still you can can use a LISP for this stuff even if it's not CL.
Keep in mind that GOAL was designed for deployment on a game console. Also, a lot of the bottle-neck issues that games face are not the same as in high performance, number crunching finance software. Games are graphics, I/O and event processing heavy. In addition, games are compile once and give it to thousands of people type software. While analysis software is often writen once, but tweaked and updated by the end user very frequently. Common Lisp would be just perfect for this type of two stage explore/optimize usage; the development environment is posh, and the performance can get as raw as you want it to be.
My intentions for playing with the language is to rewrite enough of QuantLib, a large library I feel comfortable with, for myself using Lisp so that I can eventually run an equivalent of the Equity Options Example found in the source download. It's just learning at this point, taking something I know and rewriting it in a different language in order to get to know the language better. It will take some time.
What is the problem with inline assembly? Ever heard of LAP (Lisp Assembly Program)? It appeared in Lisp 1.5 and today every decent Common Lisp has one. The sickest one is in Corman Lisp's, where all I had to do was put parenthesis around Win32 NASM code and the fucker ran it.)
IMO, if you are going to sprinkle ASM thought the program, because it really needs to be that fast then CL is probably not the best LISP dialect for you. It's just a rule of thumb and if you only care about speed for a tiny inner loop than CL is still a great choice, but if most of the app needs to be stupid fast consider your options.
Have you heard of FFIs? Foreign function interfaces? You can call ANY OS system call from Lisp, and for user-mode shared libraries you can just load them and call their functions just as easily.
Look for some applications your code needs to be as fast as possible. When your company is writing the software and spending 50million / year on HW taking a slight speed hit to use your favorite tool is not always an option.
PS: Consider how much money Honda spends on processing power for their engines and how much a 5% speed hit would cost them to fix by buying better HW.
Could highly numeric code (for quant work) run as fast as C/C++?
Yes, outside of extream optomizations. A good rule of thumb might be if you are are using inline ASM then no, otherwize yes.
PS: Common LISP is not the fastest LISP dielect, for quant work you might want something custom like GOAL. (http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp)