<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 3, 2016 at 6:27 AM, Dmitrii Kuvaiskii <span dir="ltr"><<a href="mailto:Dmitrii.Kuvaiskii@tu-dresden.de" target="_blank">Dmitrii.Kuvaiskii@tu-dresden.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I continue playing with Intel MPX and its support in modern compilers.<br>
All experiments were done on the Alienware (Dell) 15 R2, Ubuntu 15.10<br>
(linux 4.2.0), gcc version is 5.2.1, icc version 2016.1.150. The<br>
benchmark suite is PARSEC 3.0, all versions with 1 thread and default<br>
configs.<br>
<br>
As I described previously, PointerChecker in gcc produces very<br>
inefficient code. My experiments show overheads over native of up to<br>
9.5X (on "raytrace"), with common overheads of 3X ("bodytrack",<br>
"fluidanimate", "streamcluster"). At the same time, AddressSanitizer<br>
performs much better -- 1.3X on "raytrace", 1.7X on "bodytrack" and so<br>
on.<br>
<br>
Recently I played with MPX support on Intel C/C++ Compiler (icc). This<br>
implementation looks *much* better, with the following example<br>
overheads: 1.2X on "raytrace", 1.25X on "bodytrack", 1.08X on<br>
"streamcluster". So the common overheads are in the range of 15%-25%!<br></blockquote><div><br></div><div>That's interesting. </div><div>Are you sure you are instrumenting both reads and writes with icc? </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 is not<br>
Please note that gcc-mpx and gcc-asan versions were compared against<br>
gcc-native, and icc-mpx version was compared against icc-native.<br>
<br>
We would like to compile a small technical report with all our<br>
measurements (performance and memory  overhead) and put it online.<br>
We'll do it in the near future, I will write an update here when it's<br>
done. Please tell me if anyone is interested in any specific<br>
benchmarks (I want to test PARSEC and some case-studies: PostgreSQL,<br>
Memcached, SQLite3). Any feedback is welcome.<br></blockquote><div><br></div><div>SPEC2006 is well know so it could be useful. Especially 483.xalancbmk</div><div>Besides, maybe you could take something that is not strictly a benchmark. </div><div>E.g. take pdfium_test (<a href="https://pdfium.googlesource.com/pdfium/">https://pdfium.googlesource.com/pdfium/</a>) and feed several large pdf files to it. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
On Thu, Jan 28, 2016 at 8:29 PM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
> I've recently played with the GCC implementation of pointer checker on a<br>
> real hardware,<br>
> my recent impressions are here:<br>
> <a href="https://github.com/google/sanitizers/wiki/AddressSanitizerIntelMemoryProtectionExtensions" rel="noreferrer" target="_blank">https://github.com/google/sanitizers/wiki/AddressSanitizerIntelMemoryProtectionExtensions</a><br>
> (there is also some old pre-hardware content).<br>
><br>
> In short, I totally agree with what David says above: MPX is a disaster.<br>
> (Usual disclaimer: my opinion here is too biased)<br>
><br>
> I am glad that LLVM already has the support for MPX instructions, but I see<br>
> no good reason to add the MPX-based checker to LLVM.<br>
> Yes, it will allow us to detect intra-object overflows, something that asan<br>
> can not do by default, but it's not worth the extreme complexity of the<br>
> MPX-based checker.<br>
><br>
> --kcc<br>
><br>
> On Thu, Jan 28, 2016 at 9:14 AM, David Chisnall via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> On 28 Jan 2016, at 17:03, Dmitrii Kuvaiskii via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> ><br>
>> > Interestingly, my<br>
>> > preliminary experiments indicate that adding MPX bounds checking via<br>
>> > Pointer Checker in gcc is usually slower than using software-only<br>
>> > AddressSanitizer.<br>
>><br>
>> This corresponds with other results that I have seen.  The last time I<br>
>> looked at the output from gcc, it also did not generate pointer updates that<br>
>> were safe in the presence of concurrency (they must be bracketed in<br>
>> transactions if you want the MPX metadata and the pointer updates to be<br>
>> atomic) and the overhead of this is likely to be even more.<br>
>><br>
>> I am particularly impressed with Intel for creating a hardware<br>
>> implementation that is both slower than a software-only version and can not<br>
>> (due to its fail-open policy being embedded in the hardware) be used for<br>
>> security.<br>
>><br>
>> David<br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
><br>
<br>
<br>
<br>
</div></div><div class=""><div class="h5">--<br>
Yours sincerely,<br>
Dmitrii Kuvaiskii<br>
</div></div></blockquote></div><br></div></div>