<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I am guessing the JVM is optimizing away the call to fibonacci() since the results are not used, so all the tasks are doing are sleeping and waking up.<div class=""><br class=""></div><div class="">Not a good test.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 29, 2024, at 8:15 PM, robert engels <<a href="mailto:rengels@ix.netcom.com" class="">rengels@ix.netcom.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">You can see from the flame graph that the system is spending all of its time scheduling VTs and sleeping - the “work” is negligible. The is the carrier thread on my system with the most “work” (execute()) - most of the carrier threads are doing no work at all. Every carrier is spending its time going to sleep and waking back up.<div class=""><br class=""><div class=""><span id="cid:C5CFE2E4-9285-4DCB-A365-57068114C7DC"><PastedGraphic-1.png></span></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On May 29, 2024, at 7:10 PM, robert engels <<a href="mailto:rengels@ix.netcom.com" class="">rengels@ix.netcom.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Ignore that - the first set of metrics are in ms.<div class=""><br class=""></div><div class="">But the wall time within a numTasks is nearly identical regardless of scenario.<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On May 29, 2024, at 7:09 PM, robert engels <<a href="mailto:rengels@ix.netcom.com" class="">rengels@ix.netcom.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">But looking at the numbers some more they don’t make sense. The total times go way down, moving from 10_000 tasks to 100_000 tasks. Then they go up again (expected) moving from 100_000 to 1_000_000<div class=""><br class=""></div><div class="">I don’t think the wall time should ever go down when the number of tasks go up, so something doesn’t seem right.<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On May 29, 2024, at 6:03 PM, Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com" class="">attila.kelemen85@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Yeah, just realized that and sent my email pretty much literally a second after your email :)</div><div class=""><br class=""></div><div class="">Anyway, while yes in theory 1M threads are contending for the semaphore, but I don't think that should be a problem, because the contention is rather theoretical, since those "contending" VTs are just sitting in a queue, and after each release only one of them should be released. Also, I think Liam's comparison is fair, because none of the other two methods push back, so pushing back only in the VT version would be very unfair.</div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">robert engels <<a href="mailto:rengels@ix.netcom.com" class="">rengels@ix.netcom.com</a>> ezt írta (időpont: 2024. máj. 30., Cs, 0:58):<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class="">I remember that too, but in this case I don’t think it is the cause.<div class=""><br class=""></div><div class="">In the bounded/pooled thread scenario - you are only scheduling 600 threads (either platform or virtual).</div><div class=""><div class=""><br class=""></div><div class="">In “scenario #2” all 1M virtual threads are created and are contending on a sempahore. This contention on a single resource does not occur in the other scenarios - this will lead to thrashing of the scheduler.</div><div class=""><br class=""></div><div class="">I suspect if it is run under a profiler it will be obvious. With 128 carrier threads, you have increased the contention over a typical machine by an order of magnitude.<br class=""><div class=""><br class=""></div></div></div></div></blockquote></div></div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></body></html>