<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 16, 2015 at 10:11 PM, Dmitri Gribenko <span dir="ltr"><<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Nov 16, 2015 at 9:34 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>
><br>
><br>
> On Mon, Nov 16, 2015 at 9:07 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Mon, Nov 16, 2015 at 8:55 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Mon, Nov 16, 2015 at 6:59 PM, Dmitri Gribenko via llvm-dev<br>
>> > <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> >><br>
>> >> On Mon, Nov 16, 2015 at 10:03 AM, James Molloy via llvm-dev<br>
>> >> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> >> > You don't appear to have addressed my suggestion to not require a<br>
>> >> > perfect<br>
>> >> > external world, instead to measure the overhead of an imperfect world<br>
>> >> > (by<br>
>> >> > using an empty benchmark) and subtracting that from the measured<br>
>> >> > benchmark<br>
>> >> > score.<br>
>> >><br>
>> >> In microbenchmarks, performance is not additive.  You can't compose<br>
>> >> two pieces of code and predict that the benchmark results will be the<br>
>> >> sum of the individual measurements.<br>
>> ><br>
>> ><br>
>> > This sounds like an argument against microbenchmarks in general, rather<br>
>> > than<br>
>> > against James's point. James' point assumes that you are doing a<br>
>> > meaningful<br>
>> > benchmark (since, presumably, you are trying to understand the relative<br>
>> > performance in your application).<br>
>><br>
>> Any benchmarking, and especially microbenchmarking, should not be<br>
>> primarily about measuring the relative performance change.  It is a<br>
>> small scientific experiment, where you don't just get numbers -- you<br>
>> need to have an explanation why are you getting these numbers.  And,<br>
>> especially for microbenchmarks, having an explanation, and a way to<br>
>> validate it, as well as one's assumptions, is critical.<br>
>><br>
>> In large system benchmarks performance is not additive either -- when<br>
>> you have multiple subsystems, cores and queues.  But this does not<br>
>> mean that system-level benchmarks are not useful.  As any benchmarks,<br>
>> they need interpretation.<br>
><br>
><br>
> I agree with all this, but I don't understand how adding an external<br>
> function call would interfere at all. I guess I could rephrase what I was<br>
> saying as "if having an external function call prevents the benchmark from<br>
> performing its purpose, it is hard to believe that any conclusions coming<br>
> from such a benchmark would be applicable to real code". The only exceptions<br>
> I can think about are extremely low-level asm measurements (which are<br>
> written in asm anyway so this whole discussion of llvm.blackbox is<br>
> irrelevant).<br>
<br>
</div></div>The thing is, the black box function one can implement in the language<br>
would not be a perfect substitute for the real producer or consumer.<br>
<br>
I don't know about Rust, but in other high-level languages,<br>
implementing a black box as a generic function might cause an overhead<br>
due to the way generic functions are implemented,</blockquote><div><br></div><div>How does an intrinsic at IR-level avoid this? If the slowdown from generic-ness is happening at the language/frontend semantic level, then an IR intrinsic doesn't seem like it would help.</div><div><br></div><div>-- Sean Silva</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> higher than the<br>
overhead of a regular function call.  For example, the value might<br>
need to be moved to the heap to be passed as an unconstrained generic<br>
parameter.  This wouldn't be the case in real code, where the function<br>
would be non-generic, and possibly even inlined into the callee.<br>
<div class="HOEnZb"><div class="h5"><br>
Dmitri<br>
<br>
--<br>
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>>*/<br>
</div></div></blockquote></div><br></div></div>