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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Hadoop should target C++/LLVM, not Java (because of watts)

17 点作者 tfincannon大约 16 年前

9 条评论

chibea大约 16 年前
Are there any compiler features which change the ratio power consumption/clock cycles? If yes, that's what he should have talked about and give some evidence.<p>If no, let's assume power consumption is a linear function of clock cycles and focus on cycles.<p>He claims JIT would cause 'periodically run background optimizer tasks'. He does not actually state if he is talking about single or multi-processor systems. Let's assume first, he is talking about a single-processor system. Then, the background tasks are actually run on the same CPU and thus are counted in the benchmarks. If he, instead, is talking about a multi-processor (-core) system, he claims that even in a single threaded benchmark, there might be hidden cost (hidden, since runtime is improved by 'stealing' cycles from another CPU) inflected by these background tasks. He is probably right here, since besides JIT, there is e.g. garbage collection which in fact might be running concurrently on another thread. If you only measure runtime of such a benchmark it won't be an accurate measure of the power consumption. But: If you measure CPU-time/cycles of the benchmark all the threads are taken into account with all the 'hidden' costs. He provides no evidence that the benchmarks failed to do this.<p>What he could have meant is that some benchmarks use 'warm-up' to have all the hot spots JITed before measuring. He's right here: for short running tasks JIT has to be taken into account. For long running (massive data processing) tasks it is at least not obvious that JITing is slower or faster than ahead-of-time compiling. There are some opportunities for a JIT-compiler to actually use less cycles than AOT-compiled code. E.g. a virtual method call in C++ has to use the virtual function table always, this indirection might introduce additional cycles due to bad locality. A JIT compiler knowing that a particular interface call at a call-site in fact is monomorphic, can optimistically skip one level of indirection and thus save cycles.<p>The vendors of JIT compiler put much effort in the balance between JIT overhead and possible performance gain. One can assume that they know how to create meaningful benchmarks. If in doubt, provide counter-examples.<p>BTW: The correct unit of comparison would have been work/joule and not work/watt.
评论 #605342 未加载
评论 #605311 未加载
pieter大约 16 年前
It seems like he makes two errors<p>1) He thinks that you can retarget C++ code compiled to LLVM BC to multiple targets. That's not the case, you can only JIT LLVM BC to the platform you're targetting with your C++ code. That means that you might just as well take LLVM out of the picture, and compare Java vs. C++.<p>2) Java vs. C++ on 'work/watt' is almost the same as Java vs. C++ on 'work/time', given that you keep the same machine to run it on. You'll have to keep CPU utilization maximised for both, which doesn't seem unreasonable. The only thing you then have to care about is memory utilization. If Java takes (for example) 2x as much memory as C++, then just look up how much power the extra memory uses and add that to your measure. All the other stuff (Background tasks, JIT'ing, GC'ing, whatever) is already part of the 'work/time' benchmark, so you don't have to care about that.
评论 #605187 未加载
评论 #605135 未加载
akeefer大约 16 年前
It would be a far more compelling argument if there were actual numbers in there showing that for those kinds of loads Java does in fact require more wattage; for long-running processes, once the VM has JITed everything down to machine code, one might reasonably expect that it would be pretty close to the consumption of a natively compiled C++ application. He could turn out to be right, I just don't think you can take it as self-evident that the Java VM must be using more power.
lars大约 16 年前
His argument seems to be that the JIT somehow makes Java less efficient. That's plain wrong. Yes, running the JIT will take some processor juice, but you run it because you'll save processor time in the long run.<p>Yes, Java will probably use more watts than your C++ equivalent, but that's despite of the JIT, not because of it.
wglb大约 16 年前
Perhaps this is right. If it were done in C++, then the project might be later, and thus would save by delaying many node purchases, or even entire projects.<p>On the other hand, the author of the article does not factor into the equation calorie consumption of the programmers, nor the differential calorie consumption of Java programmers vs C++ programmers. Perhaps there is enough differential to close the gap.
barrettcolin大约 16 年前
Maybe I'm missing something here: Java is bad because of "dirty little secret(s) of JIT technology". But doesn't LLVM IR need to be JIT-ed as well?
tezza大约 16 年前
Easy targets have been picked as the base metrics.<p>This article reminds me of the genius who thought Google could save the world by making their homepage background <i>black</i> instead of white.[1]<p>The author should also consider how secure the JVM sandbox model is. What is the Time/Watt cost of securing the boxen if JVM is ditched ?<p>---<p><a href="http://hardware.slashdot.org/article.pl?sid=07/07/27/054249" rel="nofollow">http://hardware.slashdot.org/article.pl?sid=07/07/27/054249</a>
kqr2大约 16 年前
Ironically, google uses java (although dalvik is a modified jvm) for android whose target audience is definitely concerned with power.<p>Android also includes a lot of application hooks for power management.
评论 #605066 未加载
评论 #605274 未加载
babo大约 16 年前
Anybody has experience with Hypertable what the author mentions?
评论 #605784 未加载