Work
I don't generally post much about my work. Mostly because it's not very interesting much of the time. 90% of my job is Code Plumbing. Unsexy work designed to distribute data, or collate it into a usable form so that the other 10% of the system can do its job.
But after 9 months of such plumbing, my boss and I started trading For Realz this week.
We're just testing the waters, and flushing out bugs (lots of bugs). Made a little money yesterday, lost a little today. But the system is working, and the computational performance has been excellent.
Regarding performance: If you write software that needs to be fast, learn to use a profiler. Getting all your code properly compiled with a profiler can be a pain in the ass, and getting the application to terminate cleanly (instead of aborting or crashing when you manually terminate it) can also be tricky, particularly if you've, say, spent the last 9 months not worrying about cleanly terminating your apps when they need to die.
I say this because one important piece of the system was running extremely hot. This was a piece that I had put a good bit of time designing for throughput, so I was puzzled and worried by how much CPU time it was using. So I spent a good chunk of Friday getting it to build and terminate properly for profiling, and a good chunk of Monday profiling it.
The profile pointed out a single glaring inefficiency that took me less than half an hour to remove, and then suddenly the app was only slightly hotter than the next-busiest app in the system. The offender was something I knew to be inefficient: Boost::Format if you're curious. It's an incredibly handy (but quite inefficient) way to assemble formatted output. I still use it in a lot of places in the system (because it is so handy), but I pulled it out of the crucial bottleneck function, which reduced the CPU utilization by about 12x.
Sometimes you can get away with inefficiency. Actually, you can be inefficient nearly all the time. But there's usually going to be some piece of the system where you have to do things the smart way. However, human intuition is notoriously poor as to which piece that is, and the degree that various inefficiencies actually impact the performance of the whole system.
And that's what profilers are for.
All this is, of course, tangential to whether or not the system will actually make money. That's not strictly my job. My job is to provide my boss with the right tools to try to make money with. It's looking like I've done a good enough job so far, but the market is a fickle mistress. The next few months will be pretty exciting.
But after 9 months of such plumbing, my boss and I started trading For Realz this week.
We're just testing the waters, and flushing out bugs (lots of bugs). Made a little money yesterday, lost a little today. But the system is working, and the computational performance has been excellent.
Regarding performance: If you write software that needs to be fast, learn to use a profiler. Getting all your code properly compiled with a profiler can be a pain in the ass, and getting the application to terminate cleanly (instead of aborting or crashing when you manually terminate it) can also be tricky, particularly if you've, say, spent the last 9 months not worrying about cleanly terminating your apps when they need to die.
I say this because one important piece of the system was running extremely hot. This was a piece that I had put a good bit of time designing for throughput, so I was puzzled and worried by how much CPU time it was using. So I spent a good chunk of Friday getting it to build and terminate properly for profiling, and a good chunk of Monday profiling it.
The profile pointed out a single glaring inefficiency that took me less than half an hour to remove, and then suddenly the app was only slightly hotter than the next-busiest app in the system. The offender was something I knew to be inefficient: Boost::Format if you're curious. It's an incredibly handy (but quite inefficient) way to assemble formatted output. I still use it in a lot of places in the system (because it is so handy), but I pulled it out of the crucial bottleneck function, which reduced the CPU utilization by about 12x.
Sometimes you can get away with inefficiency. Actually, you can be inefficient nearly all the time. But there's usually going to be some piece of the system where you have to do things the smart way. However, human intuition is notoriously poor as to which piece that is, and the degree that various inefficiencies actually impact the performance of the whole system.
And that's what profilers are for.
All this is, of course, tangential to whether or not the system will actually make money. That's not strictly my job. My job is to provide my boss with the right tools to try to make money with. It's looking like I've done a good enough job so far, but the market is a fickle mistress. The next few months will be pretty exciting.