Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Amen, Those are the hard question that the python community needs to answer (I am not sure they want to answer, tho). They are also part of the reasons we are switching to Haskell. L. Don Stewart wrote: http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534 cloud computing, transactional memory and future multicore processors Get writing that multicore, STM, web app code! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best Regards, lionel Barret de Nazaris, Gamr7 Founder CTO = Gamr7 : Cities for Games http://www.gamr7.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Don Stewart ha scritto: http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534 cloud computing, transactional memory and future multicore processors Multicore support is already supported in Python, if you use multiprocessing, instead of multithreading. And scalability is not a real problem, if you write RESTful web applications. Get writing that multicore, STM, web app code! Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Multicore support is already supported in Python, if you use multiprocessing, instead of multithreading. This is one of the reasons for my other question on this list, about whether you can solve all problems using multiple isolated processes with message passing. -- Bruce Eckel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Hi Manlio and others, On Wed, Sep 17, 2008 at 14:58, Manlio Perillo [EMAIL PROTECTED] wrote: http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534 cloud computing, transactional memory and future multicore processors Multicore support is already supported in Python, if you use multiprocessing, instead of multithreading. Well, I'm a huge Python fan myself, but multiprocessing is not really a solution as much as it is a workaround. Python as a language has no problem with multithreading and multicore support and has all primitives to do conventional shared-state parallelism. However, the most popular /implementation/ of Python sacrifies this for performance, it has nothing to do with the language itself. Stackless Python is an interesting implementation of the CSP+channels paradigm though. It has been quite successfully used for a few large projects. And scalability is not a real problem, if you write RESTful web applications. Of course scalability is a real problem, ask anyone who runs a big website. I don't see how RESTful design simply removes that problem. cheers, Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Multiprocessing is hardly a solution... I realize the Python interpreter's fairly lightweight on its own, but the weight of a full unix process plus the weight of the python interpreter in terms of memory, context switching times, and finally the clunkiness of the fork() model (which is HOW many years old now?). They need a model programmers are familiar with, e.g. threads-allocate-to-cores a la Java or C, or they need a model that is entirely new or is based on source-code annotation (like Strategies and Control.Parallel). On Wed, Sep 17, 2008 at 8:58 AM, Manlio Perillo [EMAIL PROTECTED] wrote: Don Stewart ha scritto: http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534 cloud computing, transactional memory and future multicore processors Multicore support is already supported in Python, if you use multiprocessing, instead of multithreading. And scalability is not a real problem, if you write RESTful web applications. Get writing that multicore, STM, web app code! Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Hi Bruce, On Wed, Sep 17, 2008 at 15:03, Bruce Eckel [EMAIL PROTECTED] wrote: Multicore support is already supported in Python, if you use multiprocessing, instead of multithreading. This is one of the reasons for my other question on this list, about whether you can solve all problems using multiple isolated processes with message passing. Well, processing (the Python module) serves as a good example how shared memory can be emulated through message passing. Of course, performance takes a hit but since it is out there and being used by people it should tell us that is really af feasible solution. I guess the gist of the answers people posted to your question still remains, the answer depends on if you consider performance as part of the power of each approach. Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Well, I'm a huge Python fan myself, but multiprocessing is not really a solution as much as it is a workaround. Python as a language has no problem with multithreading and multicore support and has all primitives to do conventional shared-state parallelism. However, the most popular /implementation/ of Python sacrifies this for performance, it has nothing to do with the language itself. Actually, no. Neither Python nor Ruby can utilize more than a single processor using threads. The only way to use more than one processor is with processes. -- Bruce Eckel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Hi again, On Wed, Sep 17, 2008 at 15:13, Bruce Eckel [EMAIL PROTECTED] wrote: Well, I'm a huge Python fan myself, but multiprocessing is not really a solution as much as it is a workaround. Python as a language has no problem with multithreading and multicore support and has all primitives to do conventional shared-state parallelism. However, the most popular /implementation/ of Python sacrifies this for performance, it has nothing to do with the language itself. Actually, no. Neither Python nor Ruby can utilize more than a single processor using threads. The only way to use more than one processor is with processes. I wanted to make a distinction between the language and its implementation. I think you are conflating the two. If you read the Python specification there is nothing preventing you from running on two cores in parallel. The standard library does indeed have semaphores, monitors, locks etc. In fact, I'm pretty sure the Jython implementation can use multiple cores. It is just CPython that can't, as is very well known and advertised. cheers, Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Arnar Birgisson ha scritto: Hi Manlio and others, On Wed, Sep 17, 2008 at 14:58, Manlio Perillo [EMAIL PROTECTED] wrote: http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534 cloud computing, transactional memory and future multicore processors Multicore support is already supported in Python, if you use multiprocessing, instead of multithreading. Well, I'm a huge Python fan myself, but multiprocessing is not really a solution as much as it is a workaround. The real workaround is probably (and IMHO) multithreading (at least preemptive). Python as a language has no problem with multithreading and multicore support and has all primitives to do conventional shared-state parallelism. However, the most popular /implementation/ of Python sacrifies this for performance, it has nothing to do with the language itself. Stackless Python is an interesting implementation of the CSP+channels paradigm though. It has been quite successfully used for a few large projects. There is also greenlets for cooperative multithreading (but without the scheduler and channels, so you can integrate it in your event loop like Twisted). And scalability is not a real problem, if you write RESTful web applications. Of course scalability is a real problem, ask anyone who runs a big website. I don't see how RESTful design simply removes that problem. If you use asynchronous programming and multiprocessing, you *do* solve most of the problems. This is what I do in the wsgi module for Nginx. cheers, Arnar Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Both Jython and JRuby can use multicore parallelism. Which, of course, you need desperately when running in Jython and JRuby, because they're slow as christmas for most tasks. In addition, Jython is not a predictably complete version of Python and its internals are not well documented in the least, and the documentation for what CPython code will work in Jython and what won't is sadly lacking. In my experience, it doesn't make it an unusable tool, but the tasks it is suited for fall more along the lines of traditional scripting of a large working Java application. I wouldn't want to see a large app written in Jython or JRuby. -- Jeff On Wed, Sep 17, 2008 at 9:18 AM, Arnar Birgisson [EMAIL PROTECTED] wrote: Hi again, On Wed, Sep 17, 2008 at 15:13, Bruce Eckel [EMAIL PROTECTED] wrote: Well, I'm a huge Python fan myself, but multiprocessing is not really a solution as much as it is a workaround. Python as a language has no problem with multithreading and multicore support and has all primitives to do conventional shared-state parallelism. However, the most popular /implementation/ of Python sacrifies this for performance, it has nothing to do with the language itself. Actually, no. Neither Python nor Ruby can utilize more than a single processor using threads. The only way to use more than one processor is with processes. I wanted to make a distinction between the language and its implementation. I think you are conflating the two. If you read the Python specification there is nothing preventing you from running on two cores in parallel. The standard library does indeed have semaphores, monitors, locks etc. In fact, I'm pretty sure the Jython implementation can use multiple cores. It is just CPython that can't, as is very well known and advertised. cheers, Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Jefferson Heard ha scritto: Multiprocessing is hardly a solution... I realize the Python interpreter's fairly lightweight on its own, but the weight of a full unix process plus the weight of the python interpreter in terms of memory, With copy on write some memory can be saved (if you preload all the required modules in the master process). context switching times, That's probabily the same as thread switching time. And if you use asynchronous programming in each of the worker processes, you can keep the number of required processes at a minimum. and finally the clunkiness of the fork() model (which is HOW many years old now?). Old does not means bad, IMHO. [...] Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Jython 2.5 is very close to release and its goal is to be a very complete implementation, including such improbable things as ctypes. You can indeed use the underlying threads of the JVM with Jython and JRuby, but the native Python threads are prevented from running on more than one processor by the GIL. On Wed, Sep 17, 2008 at 10:23 AM, Jefferson Heard [EMAIL PROTECTED] wrote: Both Jython and JRuby can use multicore parallelism. Which, of course, you need desperately when running in Jython and JRuby, because they're slow as christmas for most tasks. In addition, Jython is not a predictably complete version of Python and its internals are not well documented in the least, and the documentation for what CPython code will work in Jython and what won't is sadly lacking. In my experience, it doesn't make it an unusable tool, but the tasks it is suited for fall more along the lines of traditional scripting of a large working Java application. I wouldn't want to see a large app written in Jython or JRuby. -- Jeff On Wed, Sep 17, 2008 at 9:18 AM, Arnar Birgisson [EMAIL PROTECTED] wrote: Hi again, On Wed, Sep 17, 2008 at 15:13, Bruce Eckel [EMAIL PROTECTED] wrote: Well, I'm a huge Python fan myself, but multiprocessing is not really a solution as much as it is a workaround. Python as a language has no problem with multithreading and multicore support and has all primitives to do conventional shared-state parallelism. However, the most popular /implementation/ of Python sacrifies this for performance, it has nothing to do with the language itself. Actually, no. Neither Python nor Ruby can utilize more than a single processor using threads. The only way to use more than one processor is with processes. I wanted to make a distinction between the language and its implementation. I think you are conflating the two. If you read the Python specification there is nothing preventing you from running on two cores in parallel. The standard library does indeed have semaphores, monitors, locks etc. In fact, I'm pretty sure the Jython implementation can use multiple cores. It is just CPython that can't, as is very well known and advertised. cheers, Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards -- Bruce Eckel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
On Wed, 17 Sep 2008, Manlio Perillo wrote: Jefferson Heard ha scritto: the weight of a full unix process plus the weight of the python interpreter in terms of memory, With copy on write some memory can be saved (if you preload all the required modules in the master process). The kernel data structures and writable pages supporting an OS-level process add up to dozens of KB whereas a language-level concurrent context should require about 1KB. context switching times, That's probabily the same as thread switching time. Competent language-level concurrency support (as in Haskell and Erlang) makes a context switch about as expensive as a function call, thousands of times faster than an OS-level process switch. Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND PLYMOUTH: EAST 3 OR 4, INCREASING 5 AT TIMES. SLIGHT. SHOWERS. GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Tony Finch ha scritto: [...] context switching times, That's probabily the same as thread switching time. Competent language-level concurrency support (as in Haskell and Erlang) makes a context switch about as expensive as a function call, thousands of times faster than an OS-level process switch. I know. But when using the term thread one usually assume kernel thread. Of course if we talk about user threads it's a whole new story. Tony. Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
What does Haskell have to say about cloud computing? -- _jsn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Bruce Eckel [EMAIL PROTECTED] wrote: Manlio Perillo [EMAIL PROTECTED] wrote: Multicore support is already supported in Python, if you use multiprocessing, instead of multithreading. This is one of the reasons for my other question on this list, about whether you can solve all problems using multiple isolated processes with message passing. What did you get out of that, by the way? -- _jsn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
jason.dusek: What does Haskell have to say about cloud computing? I'm not sure cloud computing is well-enough defined to say anything yet. paradigm in which information is permanently stored in servers on the Internet and cached temporarily on clients that include desktops, entertainment centers, table computers, notebooks, wall computers, handhelds, etc. So we're talking about JSON, online db services like Amazon bindings, HAppS nodes, et al. For which Haskell's perfectly able. Now, maybe there's some nice abstractions waiting to be found though.. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
jason.dusek: What does Haskell have to say about cloud computing? If by 'cloud computing' you wish to discuss mapReduce then: http://www.cs.vu.nl/~ralf/MapReduce/paper.pdf Map reduce in Haskell, enjoy! Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
Don Stewart [EMAIL PROTECTED] wrote: jason.dusek: What does Haskell have to say about cloud computing? I'm not sure cloud computing is well-enough defined to say anything yet. That is fair -- having something to say about cloud computing is essentially having a grand vision. I only ask because it was touched on in the original message. ...we're talking about JSON, online db services like Amazon bindings, HAppS nodes, et al. For which Haskell's perfectly able. Do HAppS nodes really function as nodes in a larger system? Does HAppS function as a cluster application server? Now, maybe there's some nice abstractions waiting to be found though... Conventionally, it is argued that the abstraction of choice is message passing; but that isn't going to take you anywhere near having a web page that people can see twice without some more abstraction. I would like to say that distributed version control is that abstraction -- that branches with a main trunk are a model for resources that is compatible with dirty-write as well as consistent read. However, as systems become more desirable from a maintenance point of view -- self-healing, easily expandable, fault tolerant -- it becomes ever more difficult to get the transactionality you need to have a main trunk. -- _jsn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Python's big challenges, Haskell's big advantages?
http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534 cloud computing, transactional memory and future multicore processors Get writing that multicore, STM, web app code! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
