Comment by nkurz | Hacker News Reader

Comment by nkurz | Hacker News Reader

Parent Full thread

Wow, that's quite a self-referential post! I don't know what Gustavo's role is within Python development, but I really don't think he understands the motivation of the core developers like Brett.

Here's from Brett's original:

  I have a finite amount of time to volunteer in helping 
  make Python what it is. Having people push upon me that   
  they either think I am failing because I can't find a 
  solution to a problem (the "complainers") or that the 
  solution that I help create is not good even though it 
  has not been implemented and proven to be a failure (the 
  "what about this?" folks) just sucks away that much more 
  time, preventing me from helping make Python better for 
  YOU. It gets to the point that I sometimes wonder why I 
  put in so much time and effort when so many people gripe 
  about the volunteer work that I put in to produce this 
  thing that is given to the world for free.

And then Gustavo:

  I apologize, but I have a very hard time reading this and 
  not complaining. 
  ...
  I know this is just yet another complaint, though. I 
  honestly cannot fix the problem either, and rather just 
  talk about it in the hope that someone who’s able to do 
  it will take care of it.

Disgusting. Could you at least make an effort to convince the developer that they personally would benefit from the massive amount of work you are demanding of them, instead of just trying to bully them into it?

More from Gustavo:

  I can’t provide ideas or solutions.. I can’t fix the 
  problem.. they don’t even care about the problem. Why am 
  I using this thing at all?

Go a little farther: how does the developer benefit from your use of this software? If you can figure out how to answer this question in the positive, you've probably figured out a much better strategy for convincing others to solve your problems for you. If you can't, perhaps there is some other software that you could buy? If the developers don't care about the 'problem', maybe it's not their problem after all?

I think it's OK to have an opinion on anything you like. You shouldn't expect anyone to fix it for free though.

I've never written a VM, and I don't think I'd be very good at it. I've written useful modules other people use, spoken at a Python conference, and have other OSS code in various places. I'm not a succubus, at least I hope I'm not. I don't even mind multithreading in Python, since I use Threads and Queues and they work just fine for my purposes. But I'm sure, other more cooler things would happen if CPython had the same kind of multithreaded coolness that Jython and IronPython have. I don't think it makes me a bad person if I say that.

I agree: it's good to have and to express opinions. But as you point out there is a real difference between "wouldn't it be cool if..." and "you really should be working on this problem of mine" instead of doing whatever it is you currently think is more important.

I don't even really know who is right about a Python GIL. When working with C, I have a strong preference for separate processes and mmaps. When working with Perl (which I use a lot more than Python), I've never really felt much urge to use threading. Aesthetically, although I haven't really used it, I think Erlang's message passing approach is much better than native threads. But maybe Gustavo's right --- better threading would indeed allow lots of cool things to be done.

That aside, what saddens me about the exchange between Gustavo and Brett is the misconnect. It strikes me as obvious that the key for Gustavo here is to show that it's in Brett's self-interest to improve threading in Python. I didn't see any attempt of this. Instead, he seems to be taking exactly the tack Brett just finished saying was ruinous to his morale.

Except Gustavo is wrong in that he has to convince Brett that free threading is a Good Thing. Part of Brett's post was we already know that - but we're not willing to sacrifice backwards compatibility for it, and we do not have/have not thought of any good solutions to fix it.

So having people say "this sucks you guys should fix it" 100x a day, with increasing levels of "you owe me" or "you suck" tone in their voices is depressing and frustrating.

I don't disagree with you, but that's just part of working on a popular project. There are plenty of armchair language designers who could of course do everything better than you.

Oh, I agree with you! But I think we both know that while we all end up growing thick skins (or quitting) it can still get under your nails and make you sad sometimes.

Especially when you've been at it awhile. Guido must have skin like a bloody rhinoceros.

> I've never written a VM, and I don't think I'd be very good at it.

It's really not that hard. You don't even have to use C, you can do it in Python. Can you write a brainfuck interpreter? Congratulations, you now have a virtual machine with eight bytecodes. Build from there.

Kein-Hong Man's "No-Frills Guide" to the Lua VM documents one set of reasonably general bytecodes. (http://luaforge.net/docman/view.php/83/98/ANoFrillsIntroToLu...) There's a good section on virtual machines in the last chapter of _The Practice of Programming_, too.

The trick to writing a good interpreter is not in the writing of it; it's in the part wherein you manage to completely avoid making any decisions you might regret in 10 years.

Oh, sure. :) But a lot of people seem to find them impossibly intimidating, one of those things that are "perceived to be magical artifacts, carefully crafted by the wizards, and unfathomable by the mere mortals."* They're really not that tricky at an implementation level, until/unless you're going for extremely high performance.

Keeping reverse compatibility is a huge pain, though. No argument there!

* From Abdulaziz Ghuloum's excellent "An Incremental Approach to Compiler Construction" (http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf).

It makes you an annoying person if you say it without any research, and without even reading any of the decade of accumulated identical discussions, on the mailing list devoted to python development, distracting contributors from actually fruitful discussions and developments.

>I've never written a VM, and I don't think I'd be very good at it

Don't be so sure, there are a lot of research in this area and it is not black magic.

I agree! I'm actually in the process of writing my first VM right now, and it's not as hard as you would think...

All projects are easy at the start. See I just open this empty file here and start typing...

Whoever said I was at the start? The prototype is nearly done, and already working in the meantime.

"The prototype is nearly done."

you're still pretty early in the project's lifecycle. software projects generally move fastest and have the least difficult challenges early on, as a general rule, in my experience. once you have a lot of users, and legacy dependencies, and have to work right on N platforms, and handle edge cases, and be performant, and the codebase becomes so big you no longer remember all the details, and maybe a few years have passed since you were working on it full-time, etc., then you'll find that velocity and agility decreases.

Disgusting. Could you at least make an effort to convince the developer that they personally would benefit from the massive amount of work you are demanding of them, instead of just trying to bully them into it?

Come on, it's 2010. Multi-core is here to stay. It's disgusting that a general-purpose language like Python has such a horrible default properties on multi-core.

Care to explain what real-world problems you had with the GIL?

I am usually the first guy to say the GIL must go, but, quite frankly, I have learned to make Zope+Plone and Django stacks scale without messing with it. If you have a 32-core server and you want to serve, say, a Zope site, just use ZEO (ZEORaid, perhaps) and 31+ ZEO clients behind your Varnish cache.

The GIL must go, but the fact the very clever people who have tried to make threading nicer have tried to get rid of it and failed indicates this is not an easy problem.

It's not about getting rid of the GIL. It's about getting rid of it without breaking compatibility with the mountain of modules written in C there are - and that experience little or no GIL problems by themselves.

And, mind you, we are talking about CPython, the canonical implementation. IIRC, neither Jython nor PyPy have the same kind of multi-core performance problem. I am not sure, but if you write your performance-critical module in RPython and then compile it into C, you won't have many GIL problems either.

While the GIL is the biggest problem I can see in CPython, for most usage scenarios, it's not a big one.

At one point, I started writing a 3D game engine in Python, with the understanding that I'd profile and if necessary re-write the necessary parts.

I've also used Panda3D, which has a lot of Python-wrapped C++ code.

Now, I don't have specific benchmarks to point to, but it's important not "prematurely pessimize", just as it's important not to optimize prematurely. In high-performance 3D games, you'd switch compilers for say a 10% gain in optimized code performance.

Ever since I've become aware of how deep the GIL problems go, I can't really justify starting to write an engine in Python, if I'm just going to have to re-write critical and error-prone parts in C++ anyway.

There's a more general principle here that applies to languages and runtimes, as well as library design. You want to be able to get started with a new component or language / runtime easily, trading ease of use for performance, BUT as the project progresses you want a way to be sure that you could beat-down or recover from any problems in a way that doesn't essentially require a re-write.

These GIL issues remove that confidence in Python, for me. It's not a win if I can only write the easy parts of my code in Python. I specifically want to use Python to write the hard parts of my code.

I agree that there doesn't seem to be an easy, or even moderately difficult solution to this problem. That makes it even worse from the point of view of advocating Python use on a project.

To summarize, it's reasonable to say "don't optimize until you know there's a problem", but you can come at it the other way from a risk-management perspective. "What is the risk that there's some dead-end due to this language / runtime that we just won't be able to overcome (because the smartest dudes who know the language inside-out, can't fix it either)."

It's sad, because I'm a huge fan of higher-level languages, but even dealing with other people's broken or retarded bindings to C or C++ libraries is a huge time sink.

At a certain point it just becomes more productive to write in C++, never mind the FUD about programmer productivity.

That said, for my current project I'm using Unity, and writing script code in Javascript and C#, but this is more about having a toolset that Just Works out of the box. It's not clear that I would choose that approach if I had to write it from scratch.

Yes, the question is whether Python intends to support the growing number of usage scenarios for which the GIL is a problem. You could write something like Cassandra or Lucene using a combination of Python and C, but the GIL prevents that.

You could write something like Cassandra or Lucene in Python. Python is a language (much like Java, BTW). You could then run it under Jython or PyPy. The GIL is unique do CPython, AFAIK.

PyPy and Jython lag far behind the current version of Python, which is defined by the implementation of CPython. Also, as I said, I would like to use a combination of Python and C. That's for a reason. The JVM does not have structured value types (structs in C). All structured types in Java have to be referenced, which is the reason why Java software eats so much more memory than software implemented in C, C++, C# or Go. Maybe PyPy can work some day, if they can catch up. That day is definately not today.

PyPy and Jython may lag behind, but that's not a huge problem. I would love to use dict comprehensions and {} sets like I can in CPython 2.7, but I know I can't always deploy against the latest version. And, more than that, I know I can work around those features. The code may look uglier, but it's usually as fast as it would be with the newest features.

And you are right - CPython is the canonical implementation of the language. The fact we can use a reference implementation in production environments is great.

You probably wouldn't be able to write something like Cassandra in Python 2.7 and expect it to run unmodified under Jython or IronPython, but you could write it in Python 2.5 and run it under both 2.7 CPython (with the expected multi-core annoyances) or under current Jython.

And you can't have painless C modules in Java either.

Actually, I believe PyPy has a GIL as well (unless they've removed it recently).

Oops... May have gotten that one wrong, but the point stands. Even if Jython is the only GIL-free implementation of Python, you can run your thread-heavy code on it.

There is no such thing as "You wouldn't be able to do [cool-multi-core-product] in Python because of the GIL"

IronPython is another GIL free Python implementation.

Are you sure you couldn't write it?

I could write it, but it would either be dog slow or take 10 times as much time to write. The only way of using multiple cores would be to implement everything on top of shared memory. That implies using no pointers in any of the data structures and implementing a custom garbage collector.

Alright, so it's not the optimal language for something with a large amount of mutable shared state being hacked at by threads. No one ever tried to bill it as the "one true language" - maybe it's better for glue in this case, or APIs or clients, etc. Maybe it needs some jython, etc.

This is why multiple languages (a diverse toolbox) and multiple interpreters each with their pros and cons is also a good thing. Each one will have its shortcomings, and it's almost impossible to achieve all of the goals of all of the modern programming languages in a single language.

So, sure - I'd love to see python used for this problem - and all problems but thats me being irrational, that will never be true. What is true is that eventually the GIL will go away, or a non cPython interpreter will rise above cPython as the defacto standard.

I don't see why it is irrational to wish that a general purpose programming language be able to run data intensive, parallel server code. It's not exactly asking for HTML to be modified so you can write signal processing code in it.

The sad thing is that a Python + C combination would actually be _more_ suitable for the task than any of the JVM based language implementations, because the JVM has the unfortunate feature of eating memory like crazy due to the lack of structured value types.

This type of application is all about conserving memory. The core data structures must be extremely tight. But they make up only like 5% of the code. So Python + C would be way superior to Java for something like Cassandra if it wasn't for the GIL.

I guess I have to practice meditation for a few years so I can one day be as relaxed about these things as you are ;-)

Well, if it was I/O bound - the GIL shouldn't bother it too much ;)

Don't mistake me for calm though, it drives me nuts :)

It's not irrational. But, since you are willing to rely on C in addition to Python, why not code the parallelizable parts in C and leave the rest in Python.

And you can always write a proof-of-concept in Python, prove the algorithm is right and rewrite the performance-sensitive parts in C. If your tests are thorough, all is good.

That's unfortunately not an option because all requests would have to go through that single threaded bottleneck to get to the parallelized C code, which is only acceptable for long running operations. For a request/response type of scenario like Cassandra, Lucene or the kind of analytics systems I'm working on it would make the whole parallelization pointless.

The realistic option is to use a separate C based process behind the usual multi-process mod_python setup. That works but is more complicated and error prone than an in-process solution. So I think that's why so many new projects that have these kinds of scenarios (NoSQL for instance) go with Java in spite of its flaws.

nkurz isn't arguing about multi-core (and various benefits thereof). He's arguing about convincing the developer that there are benefits of adding such support, instead of 'just complaining'.

On a personal note, I must say here that I've never considered the differences between the two, and I'm taking this to heart.

Here's an analogy I thought up: You go to a shanty town and announce "free apartments for everybody", and the people are excited and help you build the new apartments. When nearly complete, you announce "oops looks like we didn't design for toilets here. Guess you'll all have to go back to the shanty town for all that". I think it's understandable that people would be pissed. Pointing out that you got all that other stuff built isn't really going to cut it.

Reply on news.ycombinator.com