The Artima Developer Community
Articles | News | Weblogs | Books | Forums
Artima Forums | Articles | Weblogs | Java Answers | News
Sponsored Link •

Weblogs Forum
Reply to Guido's Reply

21 replies on 2 pages. Most recent reply: Sep 19, 2007 11:12 PM by Larry H.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 21 replies on 2 pages [ « | 1 2 ]
John Bwah

Posts: 1
Nickname: stonecyph
Registered: Sep, 2007

Re: Reply to Guido's Reply Posted: Sep 16, 2007 11:02 AM
Reply to this message Reply
Advertisement
Bruce, the languages you're looking for are called Erlang, Haskell and Mozart-Oz. Python has many design deficiencies which make it unsuitable for massive parallelization.

Try Erlang. You'll like it. It's been industrial grade for 15 years now.

Eric Hopper

Posts: 1
Nickname: omnifars
Registered: Sep, 2007

Re: Reply to Guido's Reply Posted: Sep 16, 2007 7:41 PM
Reply to this message Reply
In particular (this is to everyone, not just Guido), be careful when assuming that threads are the right solution. We came to threads through a series of steps, like the temperature being turned up on a frog in a pan of water. People assume that you "must have threads to do concurrency properly." ....

I never have. I've always thought threads were a very questionable idea to begin with. Here's a blog post of my own that I wrote:

http://omnifarious.livejournal.com/295909.html - Threads, a neccessary evil or just a bad idea in search of a problem?

Of course, applying that to Python is interesting. Perhaps a special kind of 'file' that has hooks that let you pickle things get them to another process and unpickle them really quickly?

Or maybe something that allows Python processes to share their interned string databases and a special 'shared list' or 'shared dictionary' class that automatically allocates everything in a shared area with mutex protection on accesses?

Or maybe just some sort of queue class that transparently moves objects from one address space to another. Once you shove an object into the queue it's effectively deep copied.

Maybe a special metaclass that you can derive from that tries to put all the memory for everything pointed to by the oject very close to eachother in memory so the pages it's on can be shared via COW memory mapped regions relatively easily?

Dave Aitel

Posts: 2
Nickname: daveaitel
Registered: Sep, 2007

Re: Reply to Guido's Reply Posted: Sep 17, 2007 4:24 AM
Reply to this message Reply
You're completely one-hundred percent correct here. Concurrency is the next big problem. We've solved memory management, essentially. The next big jump is getting rid of threads entirely and moving to a language that abstracts everything behind it, much as we moved away from malloc and friends. If Python 3000 makes a decent step in this direction, it'll be the language of choice for the next generation. It's not just a matter of convenience - it's a huge matter in security (my personal specialty) and programmer productivity (the whole point of Python in the first place).

James King

Posts: 1
Nickname: jking
Registered: Sep, 2007

Re: Reply to Guido's Reply Posted: Sep 17, 2007 11:17 AM
Reply to this message Reply
Linux Magazine recently profiled the concurrent programming API, OpenMP. I wish I had a link, but it would require registration either way.

Basically, the benchmark shows a diminishing return and very little performance benefit between an OpenMP enhanced application and a traditional threaded one, if memory serves correctly. In fact, there's only one specialized category where OpenMP beats out threads.

So if Python is written in C and there are no mature facilities for C that provide visible performance benefits, are we just barking up the wrong tree there?

Maybe there can be an OpenMP enhanced branch of Python or an extension for those edge-cases where the solution would benefit?

I like Guido's position. Python 3K is focusing on the language, and being a minimalist, I like Python for that reason. If you need functionality, there's a library for it. No sense bloating the core with edge-cases of a few developers; keep the language just about the language and nothing else.

Py3k seems to have that sense as it is.

(Though my problem is a tiny knit-pick with over-explicitness... ie: printf() instead of the "" % operator... but I'll live).

Leonardo Santagada

Posts: 6
Nickname: santagada
Registered: Jul, 2006

Re: Reply to Guido's Reply Posted: Sep 17, 2007 7:10 PM
Reply to this message Reply
> As i use much of C# in my daily job, i just read this
> http://msdn.microsoft.com/msdnmag/issues/07/10/Futures/defa
> ult.aspx
>
> and i feel a little sad...It is the thing i would surely
> like to see some day in our beloved Python: Parallelism
> that is supported mainly from the language/platform...

Great Article, haven't seen anything that good from microsoft in a while (if ever).

anthony boudouvas

Posts: 14
Nickname: objectref
Registered: Jun, 2007

Re: Reply to Guido's Reply Posted: Sep 18, 2007 12:06 AM
Reply to this message Reply
> > As i use much of C# in my daily job, i just read this
> >
> http://msdn.microsoft.com/msdnmag/issues/07/10/Futures/defa
>
> > ult.aspx
> >
> > and i feel a little sad...It is the thing i would
> surely
> > like to see some day in our beloved Python: Parallelism
> > that is supported mainly from the language/platform...
>
> Great Article, haven't seen anything that good from
> microsoft in a while (if ever).

Hey Leonardo...Thanks for comment on my post, i was under the impression that NOBODY took a serious look at it.

So yes, i too believe it is a great job and is is working NOW...(well, after a 2-3 months that it will be released).

Larry H.

Posts: 3
Nickname: larzluv
Registered: Sep, 2007

Re: Reply to Guido's Reply Posted: Sep 19, 2007 11:12 PM
Reply to this message Reply
John Bwah posited:

"Python has many design deficiencies which make it unsuitable for massive parallelization."

Being still a novice when it comes to threading/concurrency, would you mind listing some (or all) of these? I'm sure I'd love to learn.

I've looked at Erlang, but didn't enjoy the syntax.

Perhaps if these design deficiencies were aired-out, Python might be able to benefit from better design?


Thank you for your time,
-Larry

Flat View: This topic has 21 replies on 2 pages [ « | 1  2 ]
Topic: Reply to Guido's Reply Previous Topic   Next Topic Topic: Crossing the Rich-Client Rubicon
Sponsored Links


Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use