<div dir="ltr"><div dir="ltr">On Sat, Jan 11, 2025 at 12:09 AM John Rose <<a href="mailto:john.r.rose@oracle.com">john.r.rose@oracle.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="https://bugs.openjdk.org/browse/JDK-8285871" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8285871</a><br>
Math.multiplyHigh and multiply on same inputs can be computed faster if their computation is shared<br></blockquote><div><br></div><div>I must admit it seemed odd to me that there was a `multiplyHigh` without a corresponding `multiplyLow` but it makes sense there'd be a single CPU instruction to do both. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And FWIW, a lambda-based API could be made generic in the lambda result, so that the full BigInteger (or whatever) could be returned immediately:<br>
...<br>To work efficiently it also needs some sort of box suppression, either by reliable inlining and EA, or by handling Long as a value class.<br></blockquote><div><br></div><div>At the very least the Long box needs to be supressed so that the 64-bit safe path can be cheap. In the past, having a branch along the way defeated HotSpot's EA. Are we likely to see the Long eliminated on today's JDKs?</div><div> </div><div>Of course if we were able to get the lambda to inline as well, that would be ideal, but I have no idea if any work is being done to profile methods receiving lambdas (perhaps with a hidden marker interface or simply by virtue of being single-method interfaces?) to split and inline multiple paths. Perhaps you know of something?</div></div></div>