A success story - kudos to ScaleMM, André Mussche
A success story - kudos to ScaleMM, André Mussche
Originally shared by Russell Weetch
I have an application that creates PDF versions of invoices. They come in files of 100 records and we get up to 1000 files per batch. I use a IOmniBackgroundWorker and that works well.
The virtual machine has 16 cores allocated to it and I assign 12 cores to to the IOmniBackgroundWorker. I queue each file as a task and the expected number of threads are used.
However, the core utilisation is not ideal. When running 100 files against this it looks like 8 cores were quite active, another three were barely in use and 5 were nil.
Is there a way to get better core usage? We are trying to increase the performance bu about 10% - 15%.
Thanks.
Originally shared by Russell Weetch
I have an application that creates PDF versions of invoices. They come in files of 100 records and we get up to 1000 files per batch. I use a IOmniBackgroundWorker and that works well.
The virtual machine has 16 cores allocated to it and I assign 12 cores to to the IOmniBackgroundWorker. I queue each file as a task and the expected number of threads are used.
However, the core utilisation is not ideal. When running 100 files against this it looks like 8 cores were quite active, another three were barely in use and 5 were nil.
Is there a way to get better core usage? We are trying to increase the performance bu about 10% - 15%.
Thanks.
Amazing!
ReplyDeleteA bit of history here: at the time we had the mm contest. Not many people had access to 8 cores+, we had.... Andre and Ivo were both colleagues of mine at that point, although working for different companies. We needed (stock trading, Ivo and me) something to scale and Ivo wrote topmm, which still performs better on multi-cores than fastmm and has less assembler code. Andre improved on Ivo's concepts and yes, it really outperforms fastmm on multi-cores today.
ReplyDeleteIt also out-performs most C family provided mm's. Note I was not massively involved, but both Ivo and Andre were. And both did a proper job. So KUDOS to them.
Note these (fastmm and topmm) were written with multi-core in mind. The practical results at the time were often under-estimated, because few people had access to the real hardware. Most of us running two cores at most. Nice to see that the concept those two programmers pursued still pays dividend in 2018!
Read: ScaleMM and TopMM and FastMM... Keyboard left me..
ReplyDelete(I wrote COMMM as a joke..!).
ScaleMM is stable for production use?
ReplyDeleteDon't think any of these MMs make any allowance for NUMA though which is a very big issue on large machines.
ReplyDeleteJacek Laskowski I've been using it in production environments for years. In my experience it's been rock-solid.
ReplyDeleteOndrej Kelle As I commented, the 32 bit version appeared to be defective when inside an Excel COM addin although to be fair I did not investigate far enough to be 100% sure that was where the fault lay. I just wrote my own NUMA aware MM.
ReplyDeleteDavid Heffernan Any chance to share your own NUMA aware MM :)
ReplyDeleteI don't think so. All I did was to wrap the system heap, HeapCreate, HeapAlloc etc. I made sure that each NUMA node has its own private heap. So long as memory allocated by a thread running on a node is subsequently used primarily on that node, then you won't pay for expensive cross node memory access.
ReplyDelete