I’ve updated the github repo of the Michelacci & Ruffo (2015) example.
Now has vfoptions.divideandconquer=0. On my computer this went from 4min to 3min, my GPU is not as powerful as Michael’s so the runtime gain was not as big.
I also fixed up the calculation of unemployment duration. This is now done based on a panel data simulation, and as a double-check there is a version that computes what the age-conditional mean of the job finding probabilities would imply (which should be roughly but not exactly what the calculation from the panel data gives). This cleaned up the figure.
PS. The spacing of the second endogenous state (a2) is done to follow the original MR2015 paper exactly. The spacing of the points follows directly from the original paper which has a grid on experience ‘e’ and then a lookup table on ‘w’; since ‘e’ has no direct role in the model this replication just puts the grid on ‘w’. MR2015 use a linear spacing on e, and switching this to a grid on w gives the more exponentially-spaced grid used here.
PPS. The spikes in unemployment at age 20 and ages 61-65 do not appear in the original figure simply because the original does not plot those ages. MR2015 assume that in the first period (age 20) everyone starts in the unemployed state.
I find it interesting that Gemini was able to perform a non-trivial vectorization. Last time I used Gemini (about 6 months ago) the results were not very good. In my experience Claude and Chatgpt are significantly better than Gemini. Maybe I’ll give Gemini another try!
Divide-and-conquer evaluates less points, but is more serial. On a CPU this would always be worth while. But on GPU the less points is a benefit while the more serial is a cost; benefit=faster run time, cost=slower run time. General rule of thumb is that on bigger models divide-and-conquer is worthwhile (less points is more important than serial) while on smaller models it is not (serial is more costly than the gains from less points).
By contrast, lowmemory does not change number of points, it purely switches from parallel to serial. So lowmemory is always slower. It can still be worth turning on as it uses less GPU memory. But you only ever want to use lowmemory when it is not possible to run without it due to out-of-memory errors.