I'd like to see answers to some of the questions he raises.
Why does Pike emphasize the performance of Go's goroutine creation and channel communication when it seems to be slower than Stackless and definitely is not an order of magnitude faster?
Why indeed? Please answer us Google Engineers!
Update:
Just for fun, I ran the benchmarks myself, and added a benchmark for Fibra, because I wrote it, and I know that it is pretty slow. :-)
Go...
wdgt:tmp simon$ time ./6.out
100000
real 0m1.147s
user 0m0.646s
sys 0m0.491s
Stackless...
wdgt:tmp simon$ time python sgo.py
100000
real 0m0.532s
user 0m0.448s
sys 0m0.080s
Fibra...
wdgt:tmp simon$ time python fgo.py
100000
real 0m4.054s
user 0m3.883s
sys 0m0.153s
This is the Fibra benchmark code. It's almost the same as the Stackless example, except for the ugly "yield" statements.
import fibra
from optparse import OptionParser
parser = OptionParser()
parser.add_option("-n", type="int", dest="num_tasklets", help="how many", default=100000)
def f(left, right):
x = yield right.pop()
yield left.push(x+1)
def main():
options, args = parser.parse_args()
leftmost = fibra.Tube()
left, right = None, leftmost
for i in xrange(options.num_tasklets):
left, right = right, fibra.Tube()
schedule.install(f(left, right))
yield right.push(0)
x = yield leftmost.pop()
print x
schedule = fibra.schedule()
schedule.install(main())
schedule.run()
The results are: Stackless fast, Go slow, Fibra... forget it.
5 comments:
I read the same post but I wondered about the multicore aspect.
Stackless -IIRC- is like python monocore.
(GIL)
Go, not having this limitations, can hope to outpermform Stackless in the not-too -distant-future.
"Can hope to" can very well be true. For that reason, Stackless can hope to as well. It's just a distant hope. But my point was that Pike seemed to emphasize current Go performance, which is about 1/2 that of current Stackless, with the timing test going against Stackless.
As for Fibra, I'm impressed what can be done with yields - nice!
You're comparing apples to oranges: Message passing in a single-threaded program (Stackless) vs. message passing in a multi-threaded one (Go). Since the execution time of the test case is dominated by message passing, it's entirely unsurprising that Go is slower.
The main difference in performance is 'sys' vs 'usr' time.
In the case of Go, the OS was busy doing 'stuff' for 0.49 secs vs 0.08secs for spython.
What was that about. That needs to be investigated.
For all I've heard, they are just emphasizing velocity in compilation, not in execution...
Post a Comment