41–50 of 56 posts
Earlier quoted context omitted.
Yeah. Nothing ground-breaking here. Would still love to have a great open-source tool for this.
You mean like oprofile, dtrace, system tap, cachegrind, etc.?
I meant regarding the automatic application of rules based on profiling.
> It’s curious that we have low cache hit rates, a lot of time stalled on cache/memory, and low bandwidth utilization.
That's typical for most workloads! Software is almost never compute or bandwidth bound in my experience, but instead spends most of its time waiting on memory in pointer chasing code. This is especially true for code written in managed languages like Java (since everything typically is boxed and allocated all over the heap).
Earlier quoted context omitted.
A lot of those optimizations would no longer yield any benefits[0]. The CPU archictecture evolved a lot in 16 years, especially in branch/code prediction to the point where a correctly predicted branch (without branch_likely) has almost no cost. [0]: At least, this is true for x86 CPUs.
I've occasionally wondered how long it takes highly optimized C/C++ to be surpassed by optimizing compilers due to CPU advancement and the optimizations either making compiler optimization harder, or the optimizations target assumptions about CPU architecture that are no longer valid. That is, what is the shelf life of a very low level CPU optimization for Intel hardware.
Earlier quoted context omitted.
You mean like oprofile, dtrace, system tap, cachegrind, etc.?
Ah, I see where you may have got confused. I meant regarding the automatic application of rules based on profiling.
I find it really weird that the article says: > It’s curious that we have low cache hit rates, a lot of time stalled on cache/memory, and low bandwidth utilization. That's typical for most workloads! Software is almost never compute or bandwidth bound in my experience, but instead spends most of its time waiting on memory in pointer chasing code. This is especially true for code written in managed languages like Java…
Perhaps random access of small data causes frequent waits without utilizing the bandwidth in a way that block copies would.
The SPECint and SPECfp benchmark suites were never very tightly connected to real-world performance, but I wonder what these figures look like for SPECjbb, the java benchmark. (If I recall correctly, SPECjbb spins up an app that looks a lot like "java pet store" and runs clients against it.)
To me putting high-priority low-latency process and a low-priority high-throughput process on the same machine is a recipe for disaster - they will find some way to get entangled and hurt each other. Kudos to google for pulling this out but the article shows that you need expertise on all levels of the stack to attempt this. Most of us are better off with simply buying more boxes :)
Or we can automate this in an OS/cluster manager and safely this with everyone like we do with some many other technologies that are difficult for most of us to develop :)
Earlier quoted context omitted.
A lot of those optimizations would no longer yield any benefits[0]. The CPU archictecture evolved a lot in 16 years, especially in branch/code prediction to the point where a correctly predicted branch (without branch_likely) has almost no cost. [0]: At least, this is true for x86 CPUs.
Ditto for prefetch instructions: https://lwn.net/Articles/444336/ A MIPS is probably the exact opposite to modern (which actually means anything P6 and above) x86 CPUs in terms of performance characteristics. If I were to guess what member of the x86 family might actually benefit from such optimisation, it would be NetBurst (which itself has very different performance characteristics from every other x86 family that…
Earlier quoted context omitted.
A lot of those optimizations would no longer yield any benefits[0]. The CPU archictecture evolved a lot in 16 years, especially in branch/code prediction to the point where a correctly predicted branch (without branch_likely) has almost no cost. [0]: At least, this is true for x86 CPUs.
As a CPU architect, I can confirm that all those except possibly 2) will not yield significant benefits. Prefetching hints will only be useful when the particular code fragment is highly memory-bound because most wide superscalar microarchitectures will easily hide L1/L2 miss latencies.
At lease in my case of networking packet forwarding app, I had the profiling data to prove that was an issue.
The app code is not that long ~2000 lines of code after clean up. But it have a lot of table looks up (DDR stall) and branches for error condition checks.
Earlier quoted context omitted.
Ah, I see where you may have got confused. I meant regarding the automatic application of rules based on profiling.
What are you looking for that is not currently part of the profile guided optimization capabilities of current compilers? It has been the case for years that you can compile a program with profiling/tracing hooks, run it through a representative workload, and feed the profiler output back to the compiler to get a faster executable. That's why no Firefox you compile yourself will outperform the one you download from M…