TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Implementing, Abstracting and Benchmarking Lightweight Threads on the JVM

39 点作者 dafnap超过 11 年前

4 条评论

justinsb超过 11 年前
I noticed that you send the &quot;native threading&quot; case through your library as well. Have you compared to just using &quot;naive&quot; Java - Threads and a BlockingQueue?<p>Also: if the Google patches for the user-mode threading are adopted, will Quasar have any advantages over a JVM that uses the same syscalls? Can you explain where this would come from?<p>I think what you&#x27;ve done is genuinely cool, I&#x27;m just trying to better understand what the 10x advantage actually comes from.
评论 #7192593 未加载
donjigweed超过 11 年前
&quot;because it uses macros, the suspendable constructs are limited to the scope of a single code block, i.e. a function running in a suspendable block cannot call another blocking function; all blocking must be performed at the topmost function. It’s because of the second limitation that these constructs aren’t true lightweight threads, as threads must be able to block at a any call-stack depth&quot;<p>Can you elaborate on this a bit? Let&#x27;s say I have a function called &#x27;fetch-url&#x27; which takes a core.async channel as an argument and makes a non-blocking http request (say, using http-kit), and in the callback handler i put the result onto the channel. If I&#x27;m in some other function, in which whose body I open a core.async go block and call fetch-url from within that go block, everything is still asynchronous is it not?
评论 #7192578 未加载
RyanZAG超过 11 年前
Any chance of someone putting together a benchmark for <a href="http://www.techempower.com/benchmarks/" rel="nofollow">http:&#x2F;&#x2F;www.techempower.com&#x2F;benchmarks&#x2F;</a> for quasar? It would be nice to see how it compares to other techniques.
Fasebook超过 11 年前
Wouldn&#x27;t this kind of development target be better served by optimizing small C&#x2F;++ programs instead of trying to optimize to some abstract virtual machine implemented on top of the hardware? I mean if speed really is your goal, why not do it correctly instead of hitting yourself in the face with an extra tree before starting?
评论 #7192856 未加载
评论 #7192980 未加载