Let’s say you have the following function:
What happens if this function is exported as an ordinal function from a DLL (not an inlined piece of code inside a header) and you call it from an EXE?
Read the rest of this entry »
From the Congressional Budget Office, a graph of actual and projected federal spending:
Note that the vast majority of the growth of projected spending in Medicare and Medicaid is due to projected increases in health care costs.
The graph really says it all.
While reading the paper Dynamic Storage Allocation: A Survey and Critical Review, I quickly focused on the claim that one requires actual memory allocation traces, as opposed to simulated data, in order to properly design an optimized memory allocator. After my experience with Win32 LD_PRELOAD, I knew that I could implement a minimally invasive memory trace mechanism for existing Windows binaries. So I did.
My first task was to write a program which would launch the application we wanted to trace and log its calls to the Windows memory allocation functions. As I recommend on my Win32 LD_PRELOAD page, I used Microsoft Research’s Detours, rather than Win32 LD_PRELOAD, for the mechanism to intercept Windows function calls. The only functions I chose to intercept were HeapAlloc and HeapFree; these functions seem to be the workhorses of the Windows memory allocation world.
When my code detects a call to HeapAlloc or HeapFree, it logs basic information about the call to a file and then forwards the call to their real implementations. Reentrancy was an issue; the process of logging could potentially cause another allocation, so I had to guard against that. A more robust application would also consider multithreading scenarios more carefully.
For performance and space considerations, I decided the allocation logger would write log entries as binary records into a file. An allocation log record is 17 bytes long; a free, 13 bytes. However, memory operations are so frequent that a one minute browsing session in Firefox (including a quick visit to Google Reader), generated a 14 megabyte log file. Furthermore, the logger introduced a noticeable, although not drastic, performance hit.
With the Firefox log file in hand, I wrote a few post-processing scripts in Python to calculate some useful data, including total cumulative memory usage and a memory allocation frequency histogram. I then used Gnuplot to graph the results.
Here is the total cumulative memory usage graph for my short Firefox browsing session:
Here is the memory allocation frequency histogram. Note the log-log scale; Firefox (like most applications) is so dominated by very small allocations that the graph is useless without it. The graph has a huge spike of allocations with very small object sizes and, somewhat interestingly, a moderate one with sizes just under 10 KB.
Here is the source code to the memory trace logger.
Morgan Stanley has lost $3.7bn on subprime mortgage-linked investments in the past two months after a big market bet went disastrously wrong, the bank revealed Wednesday night.
…
Mr Kelleher said Morgan Stanley’s losses were not related to such client-linked business but were the result of a big bet at the end of last year that subprime securities prices would fall.
For some months this looked highly profitable but as subprime prices fell far further than the traders expected, the investment became heavily loss-making, due to a phenomenon known as negative convexity [emphasis mine].
Wighton, David. “M Stanley loses $3.7bn on one subprime bet.” The Financial Times 8 November 2007.
The bet that prices of subprime mortgage-linked securities were going to fall turned into a big loss because they fell too much? Bizarre. I should look into this further.
Update 2007-11-09 9:05AM: Aha!
Morgan Stanley lost its money on a badly engineered bet. It is particularly galling because its traders were right that subprime mortgages would get hit. The problem was, they had built up long super-senior mortgage exposure (which was meant to be safe) to help defray the cost of their expensive short positions. The subprime wipe-out ended up so extreme that those “safe” securities were hammered and ended up overwhelming the short positions.
“LEX COLUMN: Morgan Stanley’s hit.” The Financial Times 9 November 2007.
Rather than betting on subprime prices falling, Morgan Stanley was actually speculating that the spread between subprime and super-senior positions would widen. Unfortunately for them, they were wrong.
On July 4, I predicted the Cubs would finish 86-76. A rerun of the regression with season-ending data also predicts 86-76.
Their actual record: 85-75.
Now that the important stuff is out of the way, congratulations on winning the NL Central! Go Cubs Go!
Update 2007-10-06 9:22PM: Damn.
After a long resistance, I have finally caved and decided to use flickr to store my online photos. Here is my flickr account.
Let’s say you have a C++ function that takes a function object as a parameter and calls it:
Now let’s say you want to pass a class’s member function to call_functor() above, as in:
The STL has a pointer-to-member function adapter called std::mem_fun() which almost gets us there. Unfortunately, it doesn’t quite meet our needs because it requires us to pass a pointer to an instance of C, as in:
However, we can use std::mem_fun() if we could figure out a way to create a new functor around std::mem_fun() with &c bound as its first parameter. Unfortunately, we cannot use the STL binders (std::bind1st and std::bind2nd) because they only work on binary functions, not unary functions.
In the general case, you should use Boost’s very powerful binding library bind. However, let’s write our own simple binder for expository purposes.
First, we need a function, bind(), that returns a function object which binds a parameter, p1, to a unary function object, func. We’ll call the returned function object binder.
The class binder should store func and p1 and have an operator() which calls func with p1 as its parameter. For simplicity we’ll assume func returns void:
We can now solve the initial problem by combining our bind() with std::mem_fun():
We can make usage a little more convenient by introducing a macro:
There’s plenty of room for improvements, but it’s amazing what you can do with a little template trickery.
Like many common controls, the tooltip control supports custom drawing for maximum flexibility. This is a quick tutorial on how to use the tooltip custom draw facility.
To convert a HFONT to a LOGFONT, use the GDI function GetObject(), as in:
The code is trivial but the function took me forever to find.
Recent Comments