Jython's not bad. I've used it a lot, and it plays well with lots of Java APIs. Pretty slick, actually. I hear Java 1.7 has some new dynamic features at the JVM level. I always imagined Jython would run a lot faster if it took advantage of them. Tal, do you know if there's any work on that? Googling around a bit I'm not seeing much.<br>
<br><div class="gmail_quote">On Sun, Jul 24, 2011 at 4:32 PM, Joshua Herman <span dir="ltr"><<a href="mailto:zitterbewegung@gmail.com">zitterbewegung@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
At least erlang works for the use cases. I wasn't aware that Jython<br>
was that powerful I will have to play with it.<br>
<div><div></div><div class="h5"><br>
On Sun, Jul 24, 2011 at 3:46 PM, Tal Liron <<a href="mailto:tal.liron@threecrickets.com">tal.liron@threecrickets.com</a>> wrote:<br>
> There is an alternative: Jython, which is Python on the JVM, and has no GIL.<br>
> It's real, it works, and has a very open community. If you want to do<br>
> high-concurrency in Python, it's the way to go. (And it has other advantages<br>
> and disadvantages, of course.)<br>
><br>
><br>
> I am always a bit frightened by community attempts to create new virtual<br>
> machines for favorite languages in order to solve problem X. This shows a<br>
> huge under-estimation of what it means to create a robust, reliable,<br>
> performative generic platform. Consider how many really reliable versions of<br>
> the C standard library out there -- and how many decades they took to<br>
> mature, even with thousands of expert eyes poring over the code and testing<br>
> it. And this is without duck typing (or ANY typing), data integrity, scoping<br>
> (+call/cc), tail recursion, or any other of the other huge (and exciting)<br>
> challenges required to run a dynamic language like Python.<br>
><br>
><br>
> So, it's almost amusing to see projects like Rubinius or Parrot come to be.<br>
> Really? This is the best use of our time and effort? I'm equally impressed<br>
> by the ballsiness of Erlang to create a new virtual machine from scratch.<br>
><br>
><br>
> But those are rather unique histories. CPython has it's own unique history.<br>
> Not many people realize this, but Python is about 6 years older than Java,<br>
> and the JVM would take another decade before reaching prominence. JavaScript<br>
> engines (running in web browsers only) at the time were terrible, and Perl<br>
> was entirely interpreted (no VM). So, in fact, CPython was written where<br>
> there was no really good platform for dynamic languages. It wasn't a matter<br>
> of hubris ("not invented here") to build a VM from scratch; there was simply<br>
> no choice.<br>
><br>
><br>
> Right now, though, there are many good choices. People like Rich Hickey<br>
> (Clojure) and Martin Odersky (Scala) have it right in targeting the JVM,<br>
> although both projects are also exploring .NET/Mono. If Python were invented<br>
> today, I imagine it also would start with "Jython," instead of trying to<br>
> reinvent the wheel (well, reinvent a whole damn car fleet, really, in terms<br>
> of the work required).<br>
><br>
><br>
> One caveat: I think there is room for "meta-VM" projects like PyPy and LLVM.<br>
> These signify a real progress in architecture, whereas "yet another dynamic<br>
> VM" does not.<br>
><br>
><br>
> -Tal<br>
><br>
><br>
> On 07/24/2011 02:56 PM, Jason Rexilius wrote:<br>
><br>
>> I also have to quote:<br>
>><br>
>> "rather that, for problems for which shared-memory concurrency is<br>
>> appropriate (read: the valid cases to complain about the GIL), message<br>
>> passing will not be, because of the marshal/unmarshal overhead (plus data<br>
>> size/locality ones)."<br>
>><br>
>><br>
>> I have to say this is some of the best discussion in quite a while. Dave's<br>
>> passionate response is great as well as others. I think the rudeness, or<br>
>> not, is kinda besides the point.<br>
>><br>
>> There is a valid point to be made about marshal/unmarshal overhead in<br>
>> situations where data-manipulation-concurrency AND _user expectation_ or<br>
>> environmental constraints apply. I think that's why people have some<br>
>> grounds to be unhappy with the GIL concept (for me its a concept) in certain<br>
>> circumstances. Tal is dead on in that "scalability" means different things.<br>
>><br>
>> Oddly, I'm more engaged in this as an abstract comp sci question than a<br>
>> specific python question. The problem set applies across languages.<br>
>><br>
>> The question I would raise is if, given that an engineer understands the<br>
>> problem he is facing, are there both tools in the toolbox? Is there an<br>
>> alternative to GIL for the use-cases where it is not the ideal solution?<br>
>><br>
>> BTW, I will stand up for IPC as one of the tools in the toolbox to deal<br>
>> with scale/volume/speed/concurrency problems.<br>
>><br>
>><br>
>> On 7/24/11 1:58 PM, Tal Liron wrote:<br>
>>><br>
>>> I would say that there's truth in both approaches. "Scalability" means<br>
>>> different things at different levels of scale. A web example: the<br>
>>> architecture of Twitter or Facebook is nothing like the architecture of<br>
>>> even a large Django site. It's not even the same problem field.<br>
>>><br>
>>><br>
>>> A good threading model can be extremely efficient at certain scales. For<br>
>>> data structures that are mostly read, not written, synchronization is<br>
>>> not a performance issue, and you get the best throughput possible in<br>
>>> multicore situations. The truly best scalability would be achieved by a<br>
>>> combined approach: threading on a single node, message passing between<br>
>>> nodes. Programming for that, though, is a nightmare (unless you had a<br>
>>> programming language that makes both approaches transparent) and so<br>
>>> usually at the large scale the latter approach is chosen. One<br>
>>> significant challenge is to make sure that operations that MIGHT use the<br>
>>> same data structures are actually performed on the same node, so that<br>
>>> threading would be put to use.<br>
>>><br>
>>><br>
>>> So, what Dave said applies very well to threading, too: "you still need<br>
>>> to know what you're doing and how to decompose your application to use<br>
>>> it."<br>
>>><br>
>>><br>
>>> Doing concurrency right is hard. Doing message passing right is hard.<br>
>>> Functional (persistent data structure) languages are hard, too. Good<br>
>>> thing we're all such awesome geniuses, bursting with experience and a<br>
>>> desire to learn.<br>
>>><br>
>>><br>
>>> -Tal<br>
>>><br>
>>><br>
>>> On 07/23/2011 01:40 PM, David Beazley wrote:<br>
>>><br>
>>>>> "high performance just create multi processes that message" very<br>
>>>>> rarely have<br>
>>>>> I heard IPC and high performance in the same sentence.<br>
>>>>><br>
>>>>> Alex<br>
>>>>><br>
>>>> Your youth and inexperience is the only reason would make a statement<br>
>>>> that ignorant. Go hang out with some people doing Python and<br>
>>>> supercomputing for awhile and report back---you will find that almost<br>
>>>> significant application is based on message passing (e.g., MPI). This<br>
>>>> is because message passing has proven itself to be about the only sane<br>
>>>> way of scaling applications up to run across thousands to tens of<br>
>>>> thousands of CPU cores.<br>
>>>><br>
>>>> I speak from some experience as I was writing such software for large<br>
>>>> Crays, Connection Machines, and other systems when I first discovered<br>
>>>> Python back in 1996. As early as 1995, our group had done performance<br>
>>>> experiments comparing threads vs. message passing on some<br>
>>>> multiprocessor SMP systems and found that threads just didn't scale or<br>
>>>> perform as well as message passing even on machines with as few as 4<br>
>>>> CPUs. This was all highly optimized C code for numerics (i.e., no<br>
>>>> Python or GIL).<br>
>>>><br>
>>>> That said, in order to code with message passing, you still need to<br>
>>>> know what you're doing and how to decompose your application to use it.<br>
>>>><br>
>>>> Cheers,<br>
>>>> Dave<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Chicago mailing list<br>
>>>> <a href="mailto:Chicago@python.org">Chicago@python.org</a><br>
>>>> <a href="http://mail.python.org/mailman/listinfo/chicago" target="_blank">http://mail.python.org/mailman/listinfo/chicago</a><br>
>>><br>
>>> _______________________________________________<br>
>>> Chicago mailing list<br>
>>> <a href="mailto:Chicago@python.org">Chicago@python.org</a><br>
>>> <a href="http://mail.python.org/mailman/listinfo/chicago" target="_blank">http://mail.python.org/mailman/listinfo/chicago</a><br>
>><br>
>> _______________________________________________<br>
>> Chicago mailing list<br>
>> <a href="mailto:Chicago@python.org">Chicago@python.org</a><br>
>> <a href="http://mail.python.org/mailman/listinfo/chicago" target="_blank">http://mail.python.org/mailman/listinfo/chicago</a><br>
><br>
> _______________________________________________<br>
> Chicago mailing list<br>
> <a href="mailto:Chicago@python.org">Chicago@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/chicago" target="_blank">http://mail.python.org/mailman/listinfo/chicago</a><br>
><br>
_______________________________________________<br>
Chicago mailing list<br>
<a href="mailto:Chicago@python.org">Chicago@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/chicago" target="_blank">http://mail.python.org/mailman/listinfo/chicago</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>blogs:<br><a href="http://johnstoner.wordpress.com/" target="_blank">http://johnstoner.wordpress.com/</a><br>'In knowledge is power; in wisdom, humility.' <br>