Hi Andrew:
>I was thinking that the big (as in really big) leg up that Go has on
>Stackless is the fact that Go can take advantage of multiple cores on the
>same machine or even multiple machines working together without writing >your
>own load-balancing and etc and what-have-you, which would be a major >leg up
>over pretty much every language currently in existence.
>Would it make a difference if Dalke's goroutines were running on an 8 core
>processor rather than a single core? Stackless has the advantage of having
To the best of my knowledge, the current implementation of Go does not
support multiple cores by default (read transparently). There is a runtime
feature runtime.GOMAXPROCS(NCPU) to tell Go about other CPUs. Again, I do
little programming that requires multiple CPUs.
The focus of my talk isn't about comparing the merits of Go to Stackless
Python. Rather I am interested in the idea of using Python to prototype. In
this case, it is using Python to prototype a new feature Stackless Python
feature, select. Select is non-trivial (and I think my implementation's
optimization got it wrong so I have to work on that before tomorrow. Grrrghh).
And yes I could use a variation of it. The secondary idea is Stackless's takes
a toolbox approach to building concurrency mechanisms. A little bit of C
Stackless Python would have to be changed. However most of the heavy lifting is
done by the Stackless API. To me that says a lot. This is where comparing the
differences in APIs and approaches comes in. Here I am expanding on Richard
Tew. Forget select for a moment. There are examples I have from my WS-BPEL
experiences (i.e., Pick) which are easy to code in Stackless but would be
difficult to code in Go.
I am treating all this as a learning experience. It is also getting me to look
at C again (man am I rusty).
Cheers,
Andrew
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
