[LLVMdev] Question on Fence Instruction
陳韋任 (Wei-Ren Chen)
chenwj at iis.sinica.edu.tw
Thu Oct 18 01:09:18 PDT 2012
> The paper is "A Case for an SC-Preserving Compiler" from PLDI 2011. What I did is following their "naive SC preserving compilation", that restricts the compiler to do any reordering for potentially shared load/store instructions. The paper says the resulting code running on x86 machine (SC-preserving binary run on non-SC hardware) will get 22% slowdown comparing with a normally optimized code running on same machine (non-SC binary run on non-SC hardware). The experiment is to see how much performance will be lost by restricting the reordering of shared load/store instructions because of those disabled compiler transformations. The fences are removed from the assembly code because they are too costly so that the performance lost of compilation restriction can not be checked independently.
> The result I get shows such reordering restriction in compilation only lead to 4% slowdown, way less than the paper's report. The reason could be that the compiler does not respect SC fences so unexpected reordering is done and lead to better performance. It could also be that their implementation is different than mine. I am not sure.
Perhaps the best way is asking the authors? ;) Anyway, I skim through
the abstract and it says:
An SC-preserving compiler, obtained by restricting the optimiza-
tion phases in LLVM, a state-of-the-art C/C++ compiler, incurs an
average slowdown of 3.8% and a maximum slowdown of 34% on
a set of 30 programs from the SPLASH-2, PARSEC, and SPEC
CINT2006 benchmark suites.
Note that the average slowdown is 3.8%, which is pretty close to your
result. Parallel benchmark like SPLASH-2 and PARSEC got 22% slowdown
as described in section 3.4, I guess it's because they are parallel
programs, the re-ordering has much more impact on their performance
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
More information about the llvm-dev