One of our biggest CPU hogs is image processing library ImageMagick - and fortunately it supports OpenMP, a system for doing using multiple cores. Since it sees 24 cores, it tries to use all of them.
Perhaps unsurprisingly, this is non-optimal without tuning; but what I did find surprising was how it failed. Here's what happened when I benchmarked four iterations of our more expensive operations - resizing a 9MB, 3507x2480 PNG file to 920×651 - using from 1 to 24 threads:
[You can think of user time as measuring "CPU effort"; real time is "how long did it take?"]
When ImageMagic can't use 21+ cores, it seems to fall back to using around three. This is decidedly non-optimal. It gets worse: for smaller images, real time starts to increase around 11 cores, or even 7. And there's more overhead than actually using three; compare the larger user time values for [22] vs. [3].
This could be because it's trying to do 11*2=22 or 7*3=21 threads because of the sizes, or it could be splitting memory/cache access over multiple processors. Or it could be something completely different.
As a result, I'm limiting it to six threads on our main server, and four on our secondary - in each case, the number of physical cores on one of its CPUs. This consistently gives a 2-2.5x speedup over one thread. In some cases, it's non-optimal in terms of wall-time, but only a little - and it leaves the other cores free.
Going past that burns up excessive CPU cycles as overhead. If nothing else, this heats the system up, reducing its lifetime… it also means the cores can't be used to process web pages or database queries. This'll be more important once we deploy PostgreSQL 9.6, supporting parallel execution within a query.
tl;dr Upload processing of large images should be snappier now, whilst using less CPU time. Yay!
I miss the good ol' days, when the speed of the CPU determined the performance of the system, and good programming (or good tuning) could turn a low-end system into a functional powerhouse. Back in '02, I had a Win2000-based media server running on a Pentium 100DX with a whopping 12MB of RAM that I came across while dumpster diving. It wasn't quick, but it was usable and functional.
You'd think that it would be up to the operating system to sort out thread prioritization, and that there would be some sort of logic involved in what that prioritization would actually be, but I guess that's not the case. With many cores, comes many responsibilities~
I miss the good ol' days, when the speed of the CPU determined the performance of the system, and go
Linux does a good job, most of the time. But it's not possible to optimize for every condition, across every combination of application and system configuration, especially considering the server is also processing a varying number of database queries, images, and web pages at the same time.
I'm not sure that's even the problem here, though - there seems to be some kind of gating going on inside OpenMP (the multithreading library ImageMagick uses). For all I know, it's trying to prevent even worse performance which might be caused if it did try to run that many threads at once.
I do enjoy optimization challenges, like getting 60FPS H.265 decoding working on my old netbook and laptop recently with a custom HEVC library. You can push old hardware surprisingly far nowadays. Part of that has come through increasing use of parallelism, fixed-function hardware, and instructions such as SSE, AES and AVX… because making general-purpose instructions faster hits a thermal wall. We'll be talking a bit more about that in a forthcoming journal on Inkbunny about the latest release.
Linux does a good job, most of the time. But it's not possible to optimize for every condition, acro
My first thought was on-processor caching. But if that were the case, I'd expect to see a significant performance drop going from 12 to 13 core (or before that, depending on the layout decisions made by OpenMP's scheduler). That doesn't appear to be the case here. OpenMP might be making bad placement decisions, but I haven't really used it enough to comment on that.
If you want to go a little deeper, strace and gprof are the tools to use.
Hey, something in my wheelhouse! My first thought was on-processor caching. But if that were the c
Honestly, it was bizarre - it gave the appearance of hard-limiting it to 200% CPU when the thread count was unlimited by policy. I'm not sure how sophisticated IM's use of OpenMP is - they seem to use a lot of "split this up into static chunks of four loop iterations" directives.
I might look deeper if it gets to the point where we're running out of things to optimize, but my next task in that area will probably be using a single pipeline with parenthesized side processing and +clone 0 to generate all thumbnails at once, rather than one at a time from the same source file.
I foresee a big speedup with that, because image decode proved to be a significant factor for pngcrush - in the end we combined a CloudFlare fork (using CLMUL instructions) with the SSE2-optimized Paeth filtering present in recent versions of libpng; it sped the whole thing up by ~30%.
Honestly, it was bizarre - it gave the appearance of hard-limiting it to 200% CPU when the thread co
Yeah… I imagine it's dependant in part on what you're doing, as well as the underlying architecture. Inkbunny runs on a pair of Sandy Bridge EN server CPUs with almost twice the cache of their desktop equivalents; it helps a lot for this kind of thing.
In fairness to IM's developers, they warn that it should be tested and tuned for your application and deployment. I can't see many end-users going to the trouble, though.
Yeah… I imagine it's dependant in part on what you're doing, as well as the underlying architecture.
looks like doing the resizing asynchronously with a single thread would be the most effective use of the cpu as is, have a bunch of workers just dedicated to doing image scaling and just polling every now in the browser and then to see if it was done writing the image details out should take the user longer than scaling the image anyways
looks like doing the resizing asynchronously with a single thread would be the most effective use of
It'd be a lot faster if we did a simple scale; but to preserve quality, we're resizing with Lanczos resampling and an unsharp operation after gamma adjustment to operate within a linear colourspace.
As you say, writing images can take a while. I think there's a significant amount of time taken up with repeated image decoding, too, as noted above. It remains to be seen whether creating a pipeline with side channels will automatically perform those resize operations within threads of their own, but cutting decode operations would be a start.
Single-threaded resizing might be the most efficient use of the CPU if we were at full load (although that discounts potential benefit of clearing the cache faster so there's room for other data/processes). However, the user experience is also important - getting that 36 seconds down to 12 makes a big difference, because they're less likely to drift off to something else - so parallelizing a single operation is important. Ideally, it'd be closer to 2 sec; it often is, but that gets tricky if it's a 10MB+ original. :-D
We're not CPU-limited in terms of throughput - on average, we use maybe 3.5 of our 24 virtual cores (mostly for database operations, partly for page rendering, and partly for image processing).
It'd be a lot faster if we did a simple scale; but to preserve quality, we're resizing with Lanczos
