<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 4, 2016 at 10:40 AM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Feb 4, 2016 at 4:59 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"><span>>> 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>
> That's interesting.<br>
> Are you sure you are instrumenting both reads and writes with icc?<br>
<br>
</span>Yes, here are the exact flags I add to the usual build configuration:<br>
  -xHOST -check-pointers-mpx:rw<br></blockquote><div><br></div></span><div>Interesting, looking forward to reading your report!  </div><span class=""><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">
<br>
Note "rw" which stands for protecting read and write accesses. In the<br>
future, I will analyze how different flags affect ASan / SoftBoundCETS<br>
/ gcc-mpx / icc-mpx.<br>
I will also use a set of microbenchmarks/benchmarks (e.g., RIPE) to<br>
test the protection provided.<br>
<span><br>
> SPEC2006 is well know so it could be useful. Especially 483.xalancbmk<br>
> Besides, maybe you could take something that is not strictly a benchmark.<br>
> E.g. take pdfium_test (<a href="https://pdfium.googlesource.com/pdfium/" rel="noreferrer" target="_blank">https://pdfium.googlesource.com/pdfium/</a>) and feed<br>
> several large pdf files to it.<br>
<br>
</span>Thanks, I will report the SPEC2006 numbers as well.<br>
<div><div><br></div></div></blockquote><div><br></div></span><div>Note that SPEC2006 has several know bugs that trigger under asan.</div><div><a href="https://github.com/google/sanitizers/wiki/AddressSanitizerRunningSpecBenchmarks" target="_blank">https://github.com/google/sanitizers/wiki/AddressSanitizerRunningSpecBenchmarks</a><br></div><div>has a patch that makes SPEC2006 pass with asan. </div><div>Some of these bugs and maybe others may also trigger with an MPX checker.</div></div></div></div></blockquote><div><br></div><div>Another note: please also try to document the memory footprint. </div><div>One of unfortunate features of MPX is its large metadata storage which may in</div><div>theory consume as much as 4x more RAM than the application itself. </div><div><br></div><div>--kcc </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>--kcc </div><span class=""><div><br></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><div>
--<br>
Yours sincerely,<br>
Dmitrii Kuvaiskii<br>
</div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>