Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

cpu-intensive multithreading

2,080 views
Skip to first unread message

Patrick Useldinger

unread,
Sep 21, 2012, 11:32:35 AM9/21/12
to
Is there any portable (Win, OSX) Scheme implementation which can distribute and preempt cpu-intensive threads over several processors / cores? I am looking to port some number-crunching thing from Python and I'd love to avoid C++.

Sam Tobin-Hochstadt

unread,
Sep 21, 2012, 2:39:27 PM9/21/12
to
On Friday, September 21, 2012 11:32:35 AM UTC-4, Patrick Useldinger wrote:
> Is there any portable (Win, OSX) Scheme implementation which can distribute and preempt cpu-intensive threads over several processors / cores? I am looking to port some number-crunching thing from Python and I'd love to avoid C++.

Racket [1] provides facilities for using multiple processors and cores, in the form of futures [2] and places [3].

[1] http://racket-lang.org
[2] http://docs.racket-lang.org/reference/futures.html
[3] http://docs.racket-lang.org/reference/places.html

Patrick Useldinger

unread,
Sep 21, 2012, 4:11:24 PM9/21/12
to
On Friday, September 21, 2012 8:39:27 PM UTC+2, Sam Tobin-Hochstadt wrote:
> Racket [1] provides facilities for using multiple processors and cores, in the form of futures [2] and places [3].

I have had a look at Racket before, but
1) threads do not work for me
2) futures look a little like black magic (according to the guide, paragraph 18.10) and it's hard to predict whether they will really run in parallel, or what you can do about it
3) places will most likely not permit to share top-level variables (at least in Windows where fork() does not work as in *nix).

Does any of these permit at least read access to global variables? I know this is not recommended, but in my case it is the easiest solution without refactoring the whole program.

Sam Tobin-Hochstadt

unread,
Sep 21, 2012, 5:56:01 PM9/21/12
to
Futures are true shared-memory, and thus support read and write access to all variables. Depending on your application, futures can be very effective even if they don't guarantee parallelism. Number-crunching is a particular strength here -- see this benchmark for an example: https://github.com/plt/racket/blob/master/collects/tests/racket/benchmarks/shootout/mandelbrot-futures.rkt

Sam

Patrick Useldinger

unread,
Sep 22, 2012, 8:53:14 AM9/22/12
to
On Friday, September 21, 2012 11:56:01 PM UTC+2, Sam Tobin-Hochstadt wrote:
> Futures are true shared-memory, and thus support read and write access to all variables. Depending on your application, futures can be very effective even if they don't guarantee parallelism. Number-crunching is a particular strength here -- see this benchmark for an example: https://github.com/plt/racket/blob/master/collects/tests/racket/benchmarks/shootout/mandelbrot-futures.rkt

Thanks. I'll give it a try.

Regards,
-Patrick

Aaron W. Hsu

unread,
Sep 24, 2012, 2:27:29 AM9/24/12
to
Chez Scheme can do this. In particular, I am currently implementing a
high-performance lightweight threading system based on a work stealing
deque and atomic CAS operations. It's for an implementation of APL on top
of Scheme, and it should do quite well for number crunching. If you are
interested, I would love to have real world code to benchmark.

--
Aaron W. Hsu | arc...@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.

Patrick Useldinger

unread,
Sep 26, 2012, 9:09:20 AM9/26/12
to
On Monday, September 24, 2012 8:27:30 AM UTC+2, Aaron W. Hsu wrote:
> Chez Scheme can do this. In particular, I am currently implementing a
> high-performance lightweight threading system based on a work stealing
> deque and atomic CAS operations. It's for an implementation of APL on top
> of Scheme, and it should do quite well for number crunching. If you are
> interested, I would love to have real world code to benchmark.

Indeed it seems to fit, according to the docs. But I seem to be unable to even get a price quotation for Chez Scheme, and Petite does not fit here.

John Cowan

unread,
Sep 26, 2012, 12:45:56 PM9/26/12
to
On Wednesday, September 26, 2012 9:09:22 AM UTC-4, Patrick Useldinger wrote:

> Indeed it seems to fit, according to the
> docs. But I seem to be unable to even get a
> price quotation for Chez Scheme, and Petite
> does not fit here.

For a price quotation, talk to info at scheme dot com.

Patrick Useldinger

unread,
Sep 26, 2012, 1:57:40 PM9/26/12
to
On Wednesday, September 26, 2012 6:45:56 PM UTC+2, John Cowan wrote:
> For a price quotation, talk to info at scheme dot com.

That's what I did. The answer was:

"Thank you for your interest in Chez Scheme. Cadence Research Systems is now a part of Cisco Systems. Over time, Chez Scheme will be integrated into Cisco's offerings. As new updates become available, our team will contact you directly."
Message has been deleted

zahari....@gmail.com

unread,
Sep 28, 2012, 3:38:13 AM9/28/12
to
On Friday, September 21, 2012 6:32:35 PM UTC+3, Patrick Useldinger wrote:
> Is there any portable (Win, OSX) Scheme implementation which can distribute and preempt cpu-intensive threads over several processors / cores? I am looking to port some number-crunching thing from Python and I'd love to avoid C++.

You can try ShedSkin it will automatically generate C++ code from your Python source along with a Make file.

Robert Klemme

unread,
Sep 28, 2012, 11:32:34 AM9/28/12
to
Reminds me of the saying: "Good things come to those who wait." Well...

Kind regards

robert


--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Ludovic Courtès

unread,
Oct 3, 2012, 5:10:27 PM10/3/12
to

gavino_learning

unread,
Nov 7, 2012, 12:49:22 AM11/7/12
to
does the guile html server have threading or futures ability to use 8 cpu machine?
0 new messages