Google Is Working On An Efficiency Sanitizer To Improve Performance Problems

[phoronix]

Phoronix: Google Is Working On An Efficiency Sanitizer To Improve Performance Problems

Derek Bruening of Google has announced the company's interest in creating an "Efficiency Sanitizer" for LLVM/Clang for analyzing targeted performance problems...

http://www.phoronix.com/scan.php?page=news_item&px=LLVM-EfficiencySanitizer

[ssokolow]

I'm not familiar with LLVM's sanitizers. Do they depend on specific frontend information or would enabling ESAN for a non-C LLVM language which calls into libc for most of its OS interaction (eg. Rust) be potentially possible?

[mmstick]

I'm not familiar with LLVM's sanitizers. Do they depend on specific frontend information or would enabling ESAN for a non-C LLVM language which calls into libc for most of its OS interaction (eg. Rust) be potentially possible?

They can work with non-C languages like Rust, but implementation is difficult. There was an attempt to add support for sanitizers in Rust two months ago but that has been postponed until further notice.

[carewolf]

Seems rather limited in scope so far, still; can't hurt.

[bug77]

Seems rather limited in scope so far, still; can't hurt.

Initial iteration always are

[milkylainen]

Actually, not writing shit code is orders of magnitude better than any efficiency optimization.
I suspect this will perhaps come in somewhat handy when tuning some math kernels in the code. Otherwise, not so much.

[name99]

Actually, not writing shit code is orders of magnitude better than any efficiency optimization.
I suspect this will perhaps come in somewhat handy when tuning some math kernels in the code. Otherwise, not so much.

I do not know the ESAN team's ultimate goals, but I suspect the problem they are trying to solve is to work around some of the stupider C/C++ compiler restrictions.
For example it is well known that in many circumstances transforming AoS (Array of Structures) data to SoA (Structure of Arrays) can have dramatic performance improvements. But it is very difficult for the compiler to PROVE that this transformation is safe. (icc performs this transformation on some SPEC code, but there's a lot of controversy about them doing this, and it seems, as a practical fact, that the heuristics they use to "prove" that this transformation is safe are so specialized to SPEC that they pretty much never benefit real-world code).

SO one thing ESAN could do, for example, is provide a report suggesting an AoS to SoA transformation, or even providing the rewritten code, and asking if you want to replace it. (With, presumably, also a list of places to look where ESAN/Clang/LLVM worry that maybe the transformation is not safe and you might need to modify some additional code, or change how your code interfaces with some external code).

A similar sort of transformation would restructure the fields in a struct, perhaps to pack them in a more space efficient manner; or would suggest that fields in a struct, although declared as 64-bits wide, never hold a value larger than 16-bits, so do you maybe want to shrink their size?

These are the things I can think off of the tope of my head, but ultimately once you have machinery in place that can track data usage and performance, along with a machine model and a reporting mechanism, you can keep adding more things as you see more stupid anti-patterns in more code --- things that the compiler can't LEGALLY change, but which you can report to the user and ask them to change.

[milkylainen]

I do not know the ESAN team's ultimate goals, but I suspect the problem they are trying to solve is to work around some of the stupider C/C++ compiler restrictions.
For example it is well known that in many circumstances transforming AoS (Array of Structures) data to SoA (Structure of Arrays) can have dramatic performance improvements. But it is very difficult for the compiler to PROVE that this transformation is safe. (icc performs this transformation on some SPEC code, but there's a lot of controversy about them doing this, and it seems, as a practical fact, that the heuristics they use to "prove" that this transformation is safe are so specialized to SPEC that they pretty much never benefit real-world code).

SO one thing ESAN could do, for example, is provide a report suggesting an AoS to SoA transformation, or even providing the rewritten code, and asking if you want to replace it. (With, presumably, also a list of places to look where ESAN/Clang/LLVM worry that maybe the transformation is not safe and you might need to modify some additional code, or change how your code interfaces with some external code).

A similar sort of transformation would restructure the fields in a struct, perhaps to pack them in a more space efficient manner; or would suggest that fields in a struct, although declared as 64-bits wide, never hold a value larger than 16-bits, so do you maybe want to shrink their size?

These are the things I can think off of the tope of my head, but ultimately once you have machinery in place that can track data usage and performance, along with a machine model and a reporting mechanism, you can keep adding more things as you see more stupid anti-patterns in more code --- things that the compiler can't LEGALLY change, but which you can report to the user and ask them to change.

It is not safe to transforms structs according to compiler whim. You cannot safely tell if the struct is used for data transmission of kinds or not. There is absolutely no reordering going to happen unless you specifically tell the compiler that this struct won't be used other than internal purposes.
With regard to data pattern access optimization. Sure, that would probably encompass most of the ESAN. I suspect most of ESAN would be "whine, whine, whine". In reality, fixing all the "whine" will have little to no performance impact unless it is a math kernel code.