<p>Can anyone give me a short(ideally less than 40 lines) benchmark example of a python vs golang no channel vs golang + channel showing golang + channel > golang no channel > python in terms of speed? </p>
<p>I have been trying to understand the benchmarks in <a href="http://benchmarksgame.alioth.debian.org/" rel="nofollow">here</a>, however they are too complicate for me to understand. </p>
<hr/>**评论：**<br/><br/>Sythe2o0: <pre><p>Well, it depends on the benchmark-- in those comparisons you can see that Go doesn't out perform python on the regex-redux benchmark. </p>
<p>Furthermore, the use of channels doesn't make Go faster. If you are comparing a synchonous application and Go with channels to enable parallelism (not just concurrency), then the performance improvement will depend on the number of threads the computer can execute in parallel. </p>
<p>Yet still, it'll be faster to use raw mutexes over channels in a parallel system. Channels are not a tool for high performance applications.</p></pre>nevyn: <pre><blockquote>
<p>Yet still, it'll be faster to use raw mutexes over channels in a parallel system. Channels are not a tool for high performance applications.</p>
</blockquote>
<p>This is a bad way to think of it IMO. Yes, if you optimize all the way down you are going to be using specific locks or even lock-free/atomic magic. BUT Channels are a great way to get the easy wins.</p>
<p>Eg. You have a producer doing stuff and yield'ing results to a for loop in python, threading this will suck ... but even a single (go func() -> channel -> range) change is likely to be a significant win, and it's much easiest to have N producers or consumers.</p></pre>juniorsysadmin1: <pre><p>I just want a real world example a simple one that i could understand on why go channel is awesome. The channel is the hype about go when people talk about it. </p></pre>Sythe2o0: <pre><p>I like the <a href="https://golang.org/doc/play/sieve.go" rel="nofollow">concurrent prime sieve</a> example.</p></pre>jerf: <pre><p>Well, to some extent, there isn't much more to understand. Go is generally faster than Python. However it is certainly possible to write a program in Go to solve a problem that would be slower than one in Python, for all the reasons any two programs can be slower. What the benchmarks really say is that if you try to optimize, you can generally go farther in Go.</p>
<p>(One thing I'll warn you about is that channels, while something a Python programmer would find pretty fast, are nowhere near free. I've lost track of the number of people who post on <a href="/r/golang" rel="nofollow">/r/golang</a> "I wrote a program to add the first billion integers, and then I wrote a program that spawned a goroutine for each addition which it received via a channel and why is that hundreds of times slower?" Well, you see, on a modern processor an integer addition can take <em>less</em> than one cycle (amortized), whereas starting goroutines and using a channel can each be dozens or hundreds of instructions and maybe a few cache misses (depending), so, yeah, that's a lot slower when you do that for each addition. Goroutines and channels do not magically parallelize things for free. I mention this because I see it a lot.)</p></pre>nevyn: <pre><blockquote>
<p>One thing I'll warn you about is that channels, while something a Python programmer would find pretty fast, are nowhere near free</p>
</blockquote>
<p>But nothing is, and it's only the very beginner who thinks you need/want to parallelize obviously very serial operations. On the other hand let me introduce you to my old "friend" import multiprocessing.</p></pre>jerf: <pre><blockquote>
<p>But nothing is, and it's only the very beginner who thinks you need/want to parallelize obviously very serial operations.</p>
</blockquote>
<p>I'm not just making this up. I've seen this exact issue at least three times here. And I'm being conservative in that estimate. (I've also seen the equivalent on <a href="/r/haskell" rel="nofollow">/r/haskell</a> at least twice, and I'm sure the only reason I've never seen it on <a href="/r/erlang" rel="nofollow">/r/erlang</a> is that I don't visit there.)</p>
<blockquote>
<p>On the other hand let me introduce you to my old "friend" import multiprocessing.</p>
</blockquote>
<p>Well, I'm sure that spawning an entire process, even with fork, with a Python runtime on the other end will be even slower to add two numbers together with. I'm not sure what your point is. Nobody's claiming Python has no solution at all for "multiprocessing", but nobody sane is claiming it's going to perform anywhere near as well as Go.</p>
<p>Python is ultimately a single-threaded language, born in an era where that was the norm, and it's got a collection of hacks of varying quality to try to get around that, but there's just no retrofitting it on to an implementation that was already ten years old when they <em>started</em> to think about these issues. That's not a Python-specific criticism; I've <em>never</em> seen a 10-year-old implementation of any language grow any truly performant and usable concurrency support without the full support of a commercial enterprise behind it, and the ability to take multiple versions to shake out. Python is in fact doing the best of all the ones I've seen try, so I'm not being critical of Python specifically.</p></pre>drvd: <pre><p>May I ask why everybody is so fixed on speed? Is this the only thing to consider when choosing a technology? And if yes: Shouldn't the measurement of "speed" be a realistic one (and thus the benchmark probably complicated)? </p></pre>kaeshiwaza: <pre><p>Speed to maintain an old app matter ! (and I bet Go will win)</p></pre>nasciiboy: <pre><p>python is a language for prompts and extensions, if you use it for something else, you make a mistake</p></pre>ChristophBerger: <pre><p>Tell this the Web development, scientific, machine learning, or AI communities and watch their responses closely. (But I guess you were only joking.)</p></pre>kostix: <pre><p>There's such thing as "established practices".</p>
<p>At different points of time of the human history people were absolutely sure
a horse is the only way to move a cart and
ships made of steel would definitely sink.</p>
<p>These days you could see those established practices had
little to do with the technologies which disrupted them, eventually :-P</p></pre>
