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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Go vs. Swift vs. C++ microbenchmark

63 点作者 monort超过 9 年前

13 条评论

campoy超过 9 年前
I don&#x27;t care about micro benchmarks ... but if you&#x27;re gonna do one, make sure your code is decent.<p>By replacing the Go slice declarations (var x[]int64) with (x := make([]int64, 0, 1000000)) you&#x27;ll get an algorithm that in my iMac runs much faster:<p>- your version: 4.93s user 0.28s system 165% cpu 3.151 total<p>- my version: 1.93s user 0.04s system 168% cpu 1.165 total<p>EDIT: I&#x27;m sure this happens with all the examples, and that&#x27;s exactly my point. What is this exactly microbenchmarking? Bad programs?
评论 #11098818 未加载
评论 #11098841 未加载
评论 #11099257 未加载
评论 #11099212 未加载
评论 #11098829 未加载
DannyBee超过 9 年前
Oh microbenchmarks.<p>All of this is going to be optimized away by a sufficiently smart compiler or a compiler you tell you want to spend lots of time optimizing.<p>In general: don&#x27;t write microbenchmarks where the results can be easily statically evaluated by the compiler, unless you are testing whether the compiler can statically evaluate it (this is a reasonable thing to want to know of course, but it&#x27;s not a test of the language).<p>There are also languages which will pretty much not bother to do a lot of the the actual work, like haskell.<p>(Note: In this case, the the C++ compiler being used actually knows all the recurrences involved, but decides it&#x27;s too expensive to statically calculate the final result of sum. GCC would do the same.)
评论 #11098989 未加载
评论 #11099030 未加载
justinsb超过 9 年前
As far as micro-benchmarks go, this one is particularly egregious. It is likely completely dominated by the array reallocation. So a runtime that - say - chooses to preallocate an array at size 1000000, or to go to 1000000 at first resize would win at this benchmark. More realistically, a runtime that conserves memory by reallocating arrays with a 1.5x factor vs a 2x factor will appear slower.<p>It&#x27;s exactly because you don&#x27;t want to rely on the runtime making the right call for your use-case that you preallocate arrays where it makes a difference (i.e. where you&#x27;re appending a million items).<p>And 99% of the time you&#x27;re doing less than 100 items, and so the array reallocation behavior just doesn&#x27;t matter.
stepanhruda超过 9 年前
Concurrency model will be a big focus for Swift 4.<p>(Swift is currently v2.2, the focus of v3 is to stabilize the ABI.)
0x434D53超过 9 年前
So what&#x27;s the conclusion of this besides some useless numbers?
jsksma2超过 9 年前
&gt; &quot;But it adds some checks and GC, so Swift also exhibits a serious slowdown, though well within 2x of C++.&quot;<p>Swift does not employ GC, it uses ARC. While that may be a form of GC, it doesn&#x27;t suffer from the same &quot;slowdown&quot; that GC would in this context because ARC is doing exactly what your base case (C++) does at run-time (ARC is a compile-time tool).<p>I think if you&#x27;re going to be doing benchmarks, you should have basic knowledge on how each system works first.
chvid超过 9 年前
I really think this is mostly just testing how well the list&#x2F;vector&#x2F;array class is handling being asked to expand itself by one element a million times.
rurban超过 9 年前
If you want to compare fast languages, you need to compare C++ with rust and pony, not swift and go.
评论 #11099014 未加载
jbeja超过 9 年前
What&#x27;s the point, seriously?
autoreleasepool超过 9 年前
FYI, unary operators and C-style for loops have been depreciated in Swift.
oussama-gmd超过 9 年前
Where is Rust :)
评论 #11098967 未加载
zeckalpha超过 9 年前
And Haskell, in the comments.
marvel_boy超过 9 年前
I&#x27;d love to see Erlang here. Anyway Swift performance is impressive.