Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

See the PyPy JIT In Action

timothy posted more than 3 years ago | from the hey-those-are-good-cat-names dept.

Programming 109

derGoldstein writes "Project PyPy is an alternative implementation of Python, with the main advantage being a Just In Time (JIT) compiler which speeds up your code considerably. They've announced the first public release of jitviewer, which is a visualization tool that helps you understand how your code is being compiled by PyPy's JIT, all the way down to assembly. If you just want to see how it looks and play with it, they've set up an online demo — just select a file, and click 'Show Assembler.'"

Sorry! There are no comments related to the filter you selected.

And their gone (0)

Anonymous Coward | more than 3 years ago | (#37081654)

Slashdot DDOS machine in full effect

Re:And their gone (0)

Anonymous Coward | more than 3 years ago | (#37081686)

They should have built their site on Java.

My first time at that (0, Offtopic)

kdawson (3715) (1344097) | more than 3 years ago | (#37081792)

When I was 14 I went deep sea fishing with my g/f Jody. I was 14 and she was 19. Well it so happened that my dad who was captaining the boat was drinking a lot of beer like 2 packs of 12 and he fell sound asleep. Me and Jody were bored. So we started making out and it was real hot under the sun and we went down into the cabin and made out more. We fell asleep and when I woke up I found her hands on my giant (approx 13 inch) lovemaker. She started to rub it like a genie bottle and that felt really good. Then she took off my pants and tried to get my meat baton in her mouth but kinda choked on it. By that time I was starting to feel REAL good. So I told her to take off her bra and she said "I have to take off my shirt first silly!". So she took off her shirt and bra and rubbed my erect sausage all over her 34DD nicely tanned boobies. At that time I spurted clear stuff all over her and she laughed. This made me brake up in tears because it looked like I wasnt a man enough for her or something and then she started telling me "No thats not what I meant!!" and started making out again. So after another 10 minutes of making out we started getting hard. She took off her pants and told me to lay down. I laid down with my 13" woman pleaser sticking right up and she lowered down on to me till I was fully inserted into her birth canal. So I lasted like 30 seconds and shot like a rocket into her and bodily fluids were gushing everywhere. She looked like she was going to laugh again and I was like Im gonna punch you in the ovaries and she really started laughing then so I pushed her on her belly and rammed my meat roll in and out of her till she SCREAMED "OH RODNEY! OH RODNEY! YES YES YES!" and then my dad woke up and saw what was going on and told us to finish up. I tried to finish but was too embarrassed. When I put my clothes back on and went back to the deck my dad told me he arranged a prostitute and she was never my g/f the entire time!

Re:My first time at that (0)

Anonymous Coward | more than 3 years ago | (#37081818)

Dude, you really need to remember to log out when you have kids in the house.

Re:My first time at that (0)

Anonymous Coward | more than 3 years ago | (#37081844)

Now, I understand why python executes so fast. Good tool. Is this why the link to "online demo" is broken?

Re:And their gone (1)

kiddygrinder (605598) | more than 3 years ago | (#37081802)

plenty of high traffic sites use python

Re:And their gone (1)

sycodon (149926) | more than 3 years ago | (#37082398)

When are they going to start calling these thing YAPython and YAPerl?

Re:And their gone (0)

GooberToo (74388) | more than 3 years ago | (#37086062)

The fact this post isn't at -1 after a day wonderfully proves just how completely broken the moderation system is on slashdot. And by moderation system, I mean those who use it.

Re:And their gone (1)

jonahbron (2278074) | more than 3 years ago | (#37081794)

I think you mean "And they're gone"

Unless they actually a possess a "gone"...

...whatever that is...

Re:And their gone (0)

Anonymous Coward | more than 3 years ago | (#37081856)

Actually, GP was talking about a gone Slashdot DDOS machine, and it is believed to be a machine that scans the front page of Slashdot and randomly turns off servers the articles link to.

Go Pypy! (4, Informative)

Anonymous Coward | more than 3 years ago | (#37081770)

I love python, and pypy makes dream about the day python could be used for anything, making java irrelevant.
The language is readable, flexible, succinct, expressive and beautiful.
Programming in python is more a joy than a core, but it has always suffered from a wide performance gap in cpu intensive tasks compared to traditional static languages.
Hopefully, this is all about to change with projects like this.
It's worth noting that Pypy is more than just an alternative python implementation. It is a framework for implementing jitted compiled dynamic languages.
There are currently several works in progress with implementations of javascript, scheme, logo, php and other languages with pypy.

Re:Go Pypy! (1)

AwesomeMcgee (2437070) | more than 3 years ago | (#37081894)

Good to know, I've toyed with the idea of trying to create a javascript jit, anyone who understands crockfordscript (which these days is practically everybody, making it all the more valueable) recognizes performance is the only thing missing from what could be one hell of a good language..

Re:Go Pypy! (1)

icebraining (1313345) | more than 3 years ago | (#37081962)

Uh, both Google's V8 and Mozilla's Tracemonkey are JIT engines. There's nothing wrong about creating your own, but if it's a question of speed and not about learning, sticking with V8 is probably a better option.

Re:Go Pypy! (0)

Anonymous Coward | more than 3 years ago | (#37083090)

Well, all the major javascript engines use JIT in one form or another nowadays

Re:Go Pypy! (2)

Requiem18th (742389) | more than 3 years ago | (#37085004)

Javascript is not a nice language, it's the unholy chimera of Self and Java.

Sure it's better than how most people describe it, but there are far better languages out there.

Re:Go Pypy! (1)

thePuck77 (1311533) | more than 3 years ago | (#37088054)

Alright, give me an alternative that does the same thing. I agree...JS is a dirty, problem-inducing (rather than problem solving) language. I just don't know what else I can use to move things around and cause the useful JS effects without a refresh without JS.

Re:Go Pypy! (1)

TheStonepedo (885845) | more than 3 years ago | (#37081938)

Thanks anon!
Somebody should mod this coward up.

Re:Go Pypy! (2, Insightful)

H0p313ss (811249) | more than 3 years ago | (#37082464)

The language is readable, flexible, succinct, expressive and beautiful.

I hear it cures cancer too. Oh wait, that's Ruby. (Actually, I love Python, but I'm allergic to fanboism...)

Re:Go Pypy! (0)

Anonymous Coward | more than 3 years ago | (#37082804)

I'm allergic to insane formatting requirements.

Re:Go Pypy! (0)

Anonymous Coward | more than 3 years ago | (#37082910)

Hey, Ruby is also a beautiful language. The fact that I like Python doesn't mean I don't like other languages.
I'm simply happy to see python implementation making strides, becoming faster and better for all purposes.

Re:Go Pypy! (2)

Tumbleweed (3706) | more than 3 years ago | (#37083038)

I hear it cures cancer too. Oh wait, that's Ruby. (Actually, I love Python, but I'm allergic to fanboism...)

While it's true that Ruby cures (certain types of) cancer, it also has the unfortunate side effect of causing autism. Don't believe me? Try reading non-Ruby code written by Ruby fans.

Re:Go Pypy! (1)

sgt scrub (869860) | more than 3 years ago | (#37085986)

Your just scared because it allows one to quickly migrate U235.XML to U238.XML.

Re:Go Pypy! (3, Insightful)

Anonymous Coward | more than 3 years ago | (#37082606)

Python is not going to make Java irrelevant. Sorry. I know it hurts to be told that your religion will never become universal, but that's reality for you.

Certainly one reason for choosing Java over Python today is performance. Python is relatively slow, and sometimes throwing more hardware at the problem is not an option, and rewriting stuff in C (like Python fanboys always suggest) is not actually that easy (and brings with it all the problems of writing anything in C -- there's a reason we want to use Python or Java in the first place, right?)

But performance is only one of the reasons. The kinds of organization that choose Java appreciate a number of things it provides that Python, by design, will never provide. Such as static guarantees of any sort, or the ability to enforce the separation of public/private APIs rather than relying on "convention". (No, Python fanboys, reflection in Java does not subvert all access checks.)

There are entire classes of Python bug that are simply impossible in Java. Passing the wrong object type as a parameter. Accessing a non-existent variable because you made a typo in the name, or because you forgot that Python does not have lexical scoping. And so on. If your developers are not all the most brilliant hackers in the world -- as is the case in most Java shops -- these things are problems with Python. (No, fanboys, unit testing is not a substitute for type-checking and variable declarations. Hint: if your developers are not wonderful developers, they probably aren't wonderful test writers either.)

Python is great for small-scale projects or for enthusiasts, and it can be used for large-scale projects where you have a small team of highly-skilled developers, but those are not the markets Java is used in, and performance is not the primary reason why Java is used in those markets. After all, if all they cared about was performance, they'd use C++.

Re:Go Pypy! (2)

buchner.johannes (1139593) | more than 3 years ago | (#37082688)

The whole Java *or* Python discussion is irrelevant. You can use Jython, and take advantage of all the Python and Java libraries.

Re:Go Pypy! (1)

AtlantaSteve (965777) | more than 3 years ago | (#37082798)

The whole Java *or* Python discussion is irrelevant. You can use Jython, and take advantage of all the Python and Java libraries.

Did you not read a word that this guy wrote, or did you simply not understand any of his points?

The weaknesses that he pointed out did not deal with Python "lacking access to Java libraries". The weaknesses that were pointed out included Python's lack of compile-time type-checking, lack of real publication and enforcement of API contracts, and lack of lexical scope.

Jython addresses none of that. It does not magically transform Python from a hacky Perl-successor into a language broadly suitable for large scale enterprise development. It's just a library that lets you run your same old hacky scripts on a JVM.

Re:Go Pypy! (0)

Anonymous Coward | more than 3 years ago | (#37084426)

urr urr urr blah blah the So Called Enterprise blah blah

loosen yer khackies corporate boy I think the bloat of your self pride is cutting off circulation to your head

Re:Go Pypy! (1)

thePuck77 (1311533) | more than 3 years ago | (#37088144)

Go comeback. Really. The height of wit.

Except, you know...all of his points are valid and until we address them Python is the new Perl. Maybe you aren't old enough, Mr. Coward, but I remember when Perl was the new toy and people thought it was the best thing since sliced bread (hell, it would slice the bread for you).

Re:Go Pypy! (2, Insightful)

OeLeWaPpErKe (412765) | more than 3 years ago | (#37082748)

You're argument only makes sense if you accept that the python language design requires dynamic typing. And this may (may) be true for the really advanced and esoteric uses of python, but anyone who's ever built a tiny compiler knows that 95% of python can easily be implemented statically typed. It would be a great exercise to try to fully inline the entire python runtime library to cover the remaining 5%.

Personally I'm convinced that a statically typed python supporting 90% of common use cases, and the IDE and tools that are possible to build using such a language would blow the regular python out of the water. Python's "dynamic" typing is in reality no more powerful than inference + splitting (ie. if you do 'x = 5; print x + 1; x = "boe"; print x + "1";' translate to 'x = 5; print x + 1; y = "boe"; print y + "1"', and split the variable name when re-typing occurs). And is there anyone here claiming that java's ctrl+space wouldn't be a great help in writing library intensive python code, never mind all other refactorings ?

I may understand in practice why people use dynamically typed languages, but theoretically there is no good reason for using dynamic typing at all. Furthermore python's "garbage collector" is so extremely basic it could simply be moved to compile time (I mean that there is no theoretical problem predicting all allocations of a python program at compile time, so (if you had a year to get this right) you could make python object allocation compile to a nop.

Re:Go Pypy! (0)

Anonymous Coward | more than 3 years ago | (#37082922)

theoretically there is no good reason for using dynamic typing at all.

How about "an object is an object"? An identifier is an identifier. In a pure OO language like Smalltalk, there is no reason to limit an identifier to a particular data type - and actually no reason to make the data type static.

Re:Go Pypy! (1)

OeLeWaPpErKe (412765) | more than 3 years ago | (#37083516)

Everything is an object is not a property of dynamically typed languages, nor is it a property of static languages. It can be part of language design, or it can not be. It won't force a language to be either static or dynamically typed. Imho, usually laziness of language designers is what makes languages dynamically typed. Some at least have the decency to limit that dynamic typing to the implementation,and not build it into the design.

Personally I find the one language that actually does the "everything is an object" thing correctly is C++. Python and Ruby and the like cheat : in java parlance they only have Integers and Floats and lack int and float types (and they lack &int and &float, but so does java. Actually python only really has a BigInteger). They only have pointer types and they implement hugely confusing calling conventions (at least from the viewpoint of someone who actually knows how a computer works) (and with C++0x you could say that there is a new gaping hole in most languages : move semantics versus copy semantics)

C++ by contrast has all the options : int, int*, int&, float, float*, float&, and you can stick all of them in a collection without issues. Well, except if you're shooting yourself in the foot and there is no way for the compiler to fix it.

Re:Go Pypy! (0)

Anonymous Coward | more than 3 years ago | (#37083608)

In C++, nothing is an Object - because there is no Object.
There's no common base class that everything inherits from that describes the fundamental behaviour of an object.

I think you need to spend some time actually fully learning a language like Smalltalk - where the language doesn't get in the way of the pure Object Oriented principles.

Re:Go Pypy! (1)

shutdown -p now (807394) | more than 3 years ago | (#37087542)

Are you a Java coder? There is no need to have a common base class named "object" to define the fundamental behavior of objects.

Re:Go Pypy! (1)

KDR_11k (778916) | more than 3 years ago | (#37084374)

The reason for static typing is not implementation difficulties but bug checking. When I need an int variable I can declare it as such and make sure I never accidentally stick anything else into that variable. With dynamic typing a function can return values of different types or maybe a programming mistake makes the variable contain "3" instead of 3 and the error only pops up when something assumes you give it an int and it finds something else. In something like Lua you can have functions that return a value or nil but nil is usually in case of an error. If you don't diligently stick error handling behind every such function call you'll end up with an error many lines down and the fun trying to debug what caused the nil and where it is (if you got a few stacked tables and one of the tables in the pile is a nil it won't even tell you how deep down the nil was).

Static typing prevents user errors. Being able to detect errors where they happen greatly improves debugging and testing, helping massively with making sure the shipped product has fewer errors. The goal of modern high-level languages is to make it easier to keep the error count down and thus development costs down.

Re:Go Pypy! (0)

Anonymous Coward | more than 3 years ago | (#37091408)

The reason for static typing is not implementation difficulties but bug checking. When I need an int variable I can declare it as such and make sure I never accidentally stick anything else into that variable.

The point of dynamic typing is that it doesn't matter if you stick anything else into that variable. It's not an error.

Your problem is that you're stuck in procedural way of thinking about variables.

Re:Go Pypy! (1)

chromatic (9471) | more than 3 years ago | (#37083240)

[T]here is no theoretical problem predicting all allocations of a python program at compile time...

... until you do IO.

Re:Go Pypy! (1)

OeLeWaPpErKe (412765) | more than 3 years ago | (#37083558)

Yes, but even then you can still group them into large chunks, instead of small allocations.

Re:Go Pypy! (1)

thePuck77 (1311533) | more than 3 years ago | (#37088288)

Ding ding ding! We have a winner!

Re:Go Pypy! (1)

smallfries (601545) | more than 3 years ago | (#37083678)

So you are claiming that duck typing is not used in practice other than in esoteric projects. That is a little bit naive, consider why would something so complex be left in the language design if it was not necessary? The entire language relies on duck typing being there to make some other design decisions easier to make, for example all containers are polymorphic collections rather than the monomorphic collections in almost every other language. Your fragment of code is a single instance where forward interference would work with name splitting on use (aka ssa form). But it is not powerful enough to handle the whole language. Consider: x = Foo() if(...) else : Bar(). What type is x after the statement? In the presence of conditional branches you need some kind of phi nodes to merge the symbols. It's the same problem that ssa suffers from in maintaing the precision of modelling which values exit a computation.

That's one of the easy ones, how about d[key1] = Foo() ... d[key2] = Bar() .... Lots of different object type under different keys. Somewhere later your analyser hits the value d[some expression]. What type comes back out?

Re:Go Pypy! (0)

Anonymous Coward | more than 3 years ago | (#37084368)

You can use a structural type system of course which solves this problem.

Re:Go Pypy! (0)

Anonymous Coward | more than 3 years ago | (#37083814)

Boo [codehaus.org] is designed to be like Python, but with static typing. It's not easy for alternative languages to gain traction, though.

"if all they cared about was performance, (0)

Anonymous Coward | more than 3 years ago | (#37082986)

they'd use C++.", as you said? Funny - isn't Python written in C++ in its libraries of functions?? That said, it should have the same performance when you call its libs functions then! Your "argument" there, falls right apart.

Re:"if all they cared about was performance, (0)

Anonymous Coward | more than 3 years ago | (#37083324)

they'd use C++.", as you said? Funny - isn't Python written in C++ in its libraries of functions?? That said, it should have the same performance when you call its libs functions then! Your "argument" there, falls right apart.

...because there's absolutely no overhead from calling these functions from a dynamically typed language right? The cache-misses and pipeline stalls that will result from this are not trivial, and will have performance issues that will be orders of magnitude larger then what you see in a C++ (assuming a decent compiler that is).

UR argument falls apart fast (especially API) (0)

Anonymous Coward | more than 3 years ago | (#37083350)

1.) Those pipeline stalls would only result IFYou sent bad data to them (That's the fault of the coder or DBA for example, since you mentioned dynamically typed in your statement).

2.) Overheads from function calls are not that big. They get marshalled in process and lib loads are not "all or nothing".

(I.E./E.G. -> You only load the portion/function you need into the calling process, NOT the entire library itself!)

---

Thus, Your "argument's" are falling apart fast, and on 2 grounds:

A.) Most programmers or DBA's aren't that stupid about data sanity, not even rookies as far as dynamically typed languages.

B.) Secondly, you're making it sound as if calling out libs/dlls is some "huge overhead" well if so, how come Operating System API's work so well and fast then??

Re:Go Pypy! (2)

ThePhilips (752041) | more than 3 years ago | (#37084314)

[...] and rewriting stuff in C (like Python fanboys always suggest) is not actually that easy (and brings with it all the problems of writing anything in C -- there's a reason we want to use Python or Java in the first place, right?)

Actually, dismissing writing parts in C is not so simple. The only problem I'm aware of is the portability. And even that is handled by package/module management automatically.

Otherwise, most problem-free C programming I ever done (as C stuff goes) was Perl XS (*). Because you can leave to Perl all the mundane tasks and implement in C only the most performance-critical parts, which often have well defined input and well defined output. Even memory allocation stops being a problem: the objects one allocates in Perl XS come from Perl's GCed pool and managed automatically.

But of course, I'm not disagreeing with you in general: in Python, there are way too many cases where performance is simply unacceptable and everytime dropping into C would be a nightmare for a project of any scale.

(*) Learning Perl XS was a bitch, but I heard Python has much much more straight forward and well documented C interface.

The kinds of organization that choose Java appreciate a number of things it provides that Python, by design, will never provide.

The "number of things" are actually much more trivial this days and is not related to technical side of things: it is the pool of cheap workforce (out-sourceable too) which keeps most organizations addicted to Java.

and performance is not the primary reason why Java is used in those markets.

It is not the primary reason, but performance played its role in Java adoption. Recall why its predecessor Smalltalk never caught up: because it was dog slow and resource hungry.

Re:Go Pypy! (1)

KDR_11k (778916) | more than 3 years ago | (#37084358)

Is PyPy very different from Psyco? I've been using the latter for scripts that needed speedups.

Re:Go Pypy! (1)

Ragzouken (943900) | more than 3 years ago | (#37084412)

From what I understand, Psyco is the father of PyPy. Psyco is a finished project, and the things learnt from it are being developed and refined in the PyPy project.

Re:Go Pypy! (1)

rwa2 (4391) | more than 3 years ago | (#37090392)

I used psyco for my thesis back in 2007. It improved my SimPy runtimes by a factor of 100, merely with a simple "import psyco" in the beginning of the project!

Unfortunately psyco only works on 32-bit architectures, and after I got my degree I finally upgraded to a 64-bit system and sat on my work waiting for something to happen. Now I guess I finally need to pull it out again and see what's up.

And by see you mean (3, Funny)

Anonymous Coward | more than 3 years ago | (#37081776)

the connection has timed out

Python, the new Java

It's Python. It's Java. It's Jython. (0)

tepples (727027) | more than 3 years ago | (#37081826)

Python, the new Java

That's Jython [jython.org] , not PyPy.

Re:It's Python. It's Java. It's Jython. (0, Informative)

Anonymous Coward | more than 3 years ago | (#37082006)

umm?!? whoosh?

Re:And by see you mean (1)

rafe.kettler (1946264) | more than 3 years ago | (#37082254)

Slashdot has taken down plenty of websites written in a wide variety of languages.

Re:And by see you mean (0)

Anonymous Coward | more than 3 years ago | (#37092514)

There needs to be a +1 Oh Yeah for mod points. WE can all be proud of /. a site.

The difference between Python and Ruby devs. (-1)

Anonymous Coward | more than 3 years ago | (#37081780)

While a lot of people think that Python programmers and Ruby programmers are quite similar, I think this tool shows a pretty important difference between them.

Python programmers, on one hand, know about the underlying system that Python is running upon. They know how the OS works. They know how the hardware works and behaves. They know assembly, and understand the mapping between their high-level Python code and what's actually executed. Using this knowledge, they can take advantage of Python being a high-level language, while at the same time being able to make their code perform well enough that their end users won't even be able to tell that C or C++ wasn't used.

We see none of this from Ruby programmers. Lacking this knowledge results in them creating some of the worst-performing software our industry has ever encountered! When you try to abstract away basically everything that isn't more complex than a string, like they seem to like to do, you lose touch with reality. You don't realize that the algorithm you just implemented performs poorly because of how it's written. No, it can't be something you did wrong! It must be the OS. Yeah, it's just Linux being slow. Your code is fast!

This is why Python software is a pleasure to use, while Ruby software just leaves you hanging. Maybe sometime next week the Ruby app will perform the work you need it to perform.

Re:The difference between Python and Ruby devs. (2, Interesting)

Anonymous Coward | more than 3 years ago | (#37082166)

I'm a python fan, but I think you are being a little bit unfair with the ruby community.
Python simply has more people working on making it fast (the pypy project started 8 years ago, and only recently it started to deliver on its promises).
By the way, pypy is a framework for creating jitted dynamic languages (it's written in python, but can be used to implement any other language).
So chances are that soon, someone will write a Ruby implementation with pypy, and this ruby vm will enjoy all the performance of the python one, because it will have an automatically created just-in-time compiler.

Re:The difference between Python and Ruby devs. (-1)

Anonymous Coward | more than 3 years ago | (#37084240)

Ruby programmers started using Ruby because it was fashionable.
Python programmers started using Python because it was better.

IT'S LIKE PORN, ONLY BETTER !! (-1)

Anonymous Coward | more than 3 years ago | (#37081820)

HallyLouAnna !! And without the hubby ever knowing that my dildo is on full tilt !!

Woo hoo! (3, Informative)

93 Escort Wagon (326346) | more than 3 years ago | (#37081822)

I'm glad to see it scales well!

LLVM? (0)

jcr (53032) | more than 3 years ago | (#37081828)

Someone remind me... Isn't PyPy the implementation that's based on LLVM?

-jcr

Re:LLVM? (0)

Courageous (228506) | more than 3 years ago | (#37081846)

Here's your reminder:

http://tinyurl.com/42jo3qv [tinyurl.com]

Re:LLVM? (0)

Anonymous Coward | more than 3 years ago | (#37081922)

Link is just: http://www.lmgtfy.com/?q=pypy+llvm
So not Goatse.

Re:LLVM? (2)

rg3 (858575) | more than 3 years ago | (#37081850)

No, that was Unladen Swallow [wikimedia.org] .

Re:LLVM? (1)

MtHuurne (602934) | more than 3 years ago | (#37081852)

No, that is Unladen Swallow [wikipedia.org] .

Re:LLVM? (0)

Anonymous Coward | more than 3 years ago | (#37082092)

Nah, LLVM (with all its bugs) fucked up the whole Unladan Swallow project, which was sponsored by Google, and speculated to be used as the native Android language.

Re:LLVM? (1)

Millennium (2451) | more than 3 years ago | (#37082116)

No. IIRC it can compile to LLVM (it's actually got a bunch of backends), but it isn't actually based on LLVM itself.

Not a big fan of Python, but... (0)

Anonymous Coward | more than 3 years ago | (#37081874)

Not a big fan of Python, but at some point I decided that an important check-off for any language is whether or not it can self-compile (or self interpret). PyPy gives it that checkoff and hat's off for having a JIT.

Compare and contrast with Larry Wall's admission that Perl isn't for everything, noting that Perl isn't written in Perl. In retrospect, that should have been a red flag. C is written in C, Lisp is written in Lisp to the point where it makes your mind warp. Not sure about Java; but it seems likely that somebody has done it.

Re:Not a big fan of Python, but... (1)

icebraining (1313345) | more than 3 years ago | (#37082000)

I think Rakudo Star is written in Perl 6 (or a subset of it). At least that was my understanding after listening to one of its devs talk about its history.

Re:Not a big fan of Python, but... (1)

Mitchell314 (1576581) | more than 3 years ago | (#37082154)

I think javac is a java program.

Re:Not a big fan of Python, but... (1)

Anonymous Coward | more than 3 years ago | (#37082246)

Javac is in java, yes, but the JVM is written in C++.

IBM's Jikes RVM is a JVM written in Java. They use it as a research platform (the R stands for "research").

Another example of Open Source showing immaturity (-1, Troll)

Anonymous Coward | more than 3 years ago | (#37081886)

I guess many open source developers are nothing but immature kids. So now we have a project cleverly named penis?

Seriously, what the hell is wrong with OSS and their lack of basic maturity? Why does open source always have to use stupid names?

Re:Another example of Open Source showing immaturi (1)

thetoadwarrior (1268702) | more than 3 years ago | (#37082060)

So what is named after a penis?

Re:Another example of Open Source showing immaturi (1)

Anonymous Coward | more than 3 years ago | (#37082118)

I think he is pronouncing PyPy as "pee-pee" instead of "pie-pie".

Re:Another example of Open Source showing immaturi (1)

whoop (194) | more than 3 years ago | (#37082394)

Good idea. I say we shall henceforth pronouce this language as Pee-thon.

Re:Another example of Open Source showing immaturi (2)

JonySuede (1908576) | more than 3 years ago | (#37083082)

sorry for the accidental drunken redundant moderation. I deeply apologize.

Quora (2, Interesting)

Anonymous Coward | more than 3 years ago | (#37082406)

quora.com is now running on PyPy.

http://www.quora.com/Alex-Gaynor/Quora-product/Quora-is-now-running-on-PyPy

Faster than C? (3, Informative)

lee1 (219161) | more than 3 years ago | (#37082974)

Not just faster than CPython, but faster than C [blogspot.com] for some common tasks. Pretty amazing.

However, this project is not yet very useful to the people who might be most interested in a really fast python, as it does not work with numpy [blogspot.com] . But when they get that to work, wow.

Re:Faster than C? (0)

Anonymous Coward | more than 3 years ago | (#37083058)

This was for one example, Python has, and will remain eternally slower than C.

I'd love to see how PyPy stacks up to LuaJIT.

Re:Faster than C? (1)

whiteboy86 (1930018) | more than 3 years ago | (#37083428)

Dream on, its like those 'over unity' energy source claims.

Re:Faster than C? (0)

Anonymous Coward | more than 3 years ago | (#37083560)

it's nice. but do we know it's not just obvious optimisation?
in his test the python and c code don't return values, nor print values (ie. no i/o)
if i made a jit compiler and encountered a loop that changed nothing external to it, and resulted in no i/o, i'd call roll it up as a nop and remove it

or a more obvious optimisation would be to allocate a block of memory
in the loop let the string be allocated to the start of the block
knowing the data is local scope only, no point expanding memory or moving the point in the memory block
so simply keep writing the result to the same spot over and over again

Re:Faster than C? (0)

Anonymous Coward | more than 3 years ago | (#37083856)

... comparison is missing how it was timed:

It took 0.85 seconds to execute under PyPy, and 1.63 seconds with the compiled binary.

this could easily mean the c binary was timed when the person pressed enter to execute the c binary, to when it returned back to the prompt (ie. timex)
whereas pypy could be using timing from the virtual machine so starts at the beginning of actual script execution after having compiled it 'just in time', and stops when the script finishes, but not before the vm kicks in cleaning up all the crap the script left behind

which from one standpoint is fair enough as you're really comparing the "compiled" code execution
from another standpoint though it's just plain bollocks as it doesn't account for the virtual machine

my comments are speculation due to lack of detail from the source material

overall i'm not trying to detract from python
for an interpretted language it has the potential to run damn fast
but i wouldn't be using it for any big iron or critical systems anytime soon

Re:Faster than C? (1)

nzac (1822298) | more than 3 years ago | (#37083948)

Did you read the comments?
That's not a common task if he created a file with a meaningful output it would be a good benchmark.

This looks to either be a stumbled on case or something contrived. He used -O4 for crying out loud (it's treated as -O3) there could be a bug from excessive optimization and the main function sprintf cannot be optimized as its a pre complied library (i could be wrong here).

The result is best summed up by the comment:

PyPy does nothing 1.9 times faster than C.

Re:Faster than C? (1)

lee1 (219161) | more than 3 years ago | (#37085444)

As he says himself, "the sprintf function lives in libc and so cannot be specializing over the constant string, which has to be parsed every time it's executed. In the case of PyPy, we specialize the assembler if we detect the left hand string of the modulo operator to be constant."

Re:Faster than C? (1)

nzac (1822298) | more than 3 years ago | (#37089546)

So what they are really saying is pypy is faster than a function in glibc for a task that glibc would never be used for (i would think you chose a modern library if you wanted to do this in some real code).
This is benchmarking not against C but a bloated and not particularly optimized library.

Re:Faster than C? (1)

m50d (797211) | more than 3 years ago | (#37092690)

Huh? How else would you do the given task in C? And glibc is the standard C library on most current linucies. It's absolutely a relevant comparison.

Re:Faster than C? (1)

nzac (1822298) | more than 3 years ago | (#37092960)

If you were going to do this as a one off sure you would use libc if you are going to do the same thing 10000 times in a row as you entire program and care about performance you would look for something better (this would likely be libboost in C++).

For anything to do with strings python is far more expressive than c and this case could be the more elegant and robust solution (except for memory usage). For this example i guess you 'parse' (not sure if that's the correct term in C) the text before the looping and store the result in a structure and then while looping though pass the structure as an argument this requires new libraries or you to write your own. Unless you allow on the fly editing in python I think its still equivalent function.

http://www.cplusplus.com/reference/clibrary/cstdio/sprintf/ [cplusplus.com]
http://bstring.sourceforge.net/features.html [sourceforge.net]
The first shows that the sprintf is bloated for the benchmarks purpose.
The second link is of library i found from google that says it has 3980% increased performance for string concatenation (other improvements are more modest) over libc if this figure is correct then a pypy has not beaten c and that sprintf is pretty bloated. I don't not check it had the equivalent functions for this problem. Its difficult to argue this as coming up with an alternative way to do nothing in C has arbitrary rules.

Re:Faster than C? (0)

Anonymous Coward | more than 3 years ago | (#37084174)

If you're comparing speed against C code that spends significant time doing mallocs then you're not comparing against high-performance C code.

Re:Faster than C? (1)

complex_pi (2030154) | more than 3 years ago | (#37085470)

Also, it needs to be able to call C and Fortran libraries to be really useful in NumPy. Because no one is going to rewrite all of those numerical libraries.

PyPy solves a very hard problem, but is still slow (4, Informative)

Animats (122034) | more than 3 years ago | (#37082980)

It's an impressive effort that they were able to get this to work at all. Python is really tough to optimize. All bindings are changeable at any time, even from another thread. (The latter is silly, but since it doesn't cost anything to do that in CPython, which is an inefficient naive interpreter that can only run one thread at a time and spends much of its time doing dictionary lookups. Von Rossum defines the language by what CPython can do. There's a huge speed penalty for allowing such extreme dynamism, about 60x over C/C++. The Google team tried to fix that with Unladen Swallow, but gave up when their JIT system was barely faster than CPython.)

PyPy's most effective optimization to date is that it figures out when numbers don't have to be boxed. This allows generating numeric machine code, rather than grinding through the object machinery for every number. They have to be prepared to discard code when something binding gets changed. This requires a very complex system, involving two interpreters (regular and backup) as well as the JIT compiler.

The PyPy crowd is at last starting on the tougher optimizations, like hoisting some operations out of loops. (FORTRAN compilers were doing this in the 1960s.) That's real progress, but it's very hard to do in such a dynamic language.

Many of the optimizations involve generating run-time code that checks to see if the normal case is occurring, and that no other code has patched the code or changed the data from the outside in a way that invalidates the fast path. Then there's code to unwind what the fast path was doing, and interpret or recompile. Most such code is never executed.

Re:PyPy solves a very hard problem, but is still s (1)

jgrahn (181062) | more than 3 years ago | (#37083204)

There's a huge speed penalty for allowing such extreme dynamism, about 60x over C/C++.

That number is surely made up; perhaps it applies to some specific set of benchmarks? In reality the factor is going to vary widely depending on the problem. And oh, you can't lump C and C++ together and call them C/C++.

Re:PyPy solves a very hard problem, but is still s (1)

smallfries (601545) | more than 3 years ago | (#37083706)

It matches what I've seen. I've written compilers, static analysers and visualisation code in Python. In most cases there is about a 100x difference in speed between the Python code and C code to implement the same algorithm. Python is still useful for prototyping in as most of that code could be written 5x to 10x more quickly than the C code.

Re:PyPy solves a very hard problem, but is still s (0)

Anonymous Coward | more than 3 years ago | (#37089878)

In my experience, C tends to compile to about 1-6 lines of asm instructions, virtually all of which are necessary to perform the required task.

If you get 60 times faster than that without changing your algorithms, even with hand-coded assembly and intimate knowledge of the hardware, you're probably bypassing the entire CPU and running on moonjuice.

Re:PyPy solves a very hard problem, but is still s (1)

dkf (304284) | more than 3 years ago | (#37091894)

Higher-level languages produce more asm per line but express more operations per line too. Easier to (validly) compare at the level of functions or whole programs.

If you get 60 times faster than that without changing your algorithms, even with hand-coded assembly and intimate knowledge of the hardware, you're probably bypassing the entire CPU and running on moonjuice.

Or spotting that something can be evaluated to a constant during compilation. That's a huge win when you can do it.

Of course, the other thing is that it is ever-so possible to write poor C code that can be out-performed by code generated from another language. A classic example of this is in string handling, where the C standard library routines can easily be used to create code with an awful performance, e.g., by repeatedly calling strcat() on the same long string, and any language with a string data structure more suited to repeated appending will outperform that. OTOH, a truly good C programmer will be using the right data structures and algorithms in the first place, making this a bit of a moot point.

Re:PyPy solves a very hard problem, but is still s (1)

smallfries (601545) | more than 3 years ago | (#37093584)

Actually he just completely misread my post. The 60x increase was Python -> C, not from C -> assembly.

Re:PyPy solves a very hard problem, but is still s (1)

smallfries (601545) | more than 3 years ago | (#37083720)

I noticed that their progress seemed to have stopped, is there any official announcement?

The Google team tried to fix that with Unladen Swallow, but gave up when their JIT system was barely faster than CPython.)

Re:PyPy solves a very hard problem, but is still s (1)

Animats (122034) | more than 3 years ago | (#37086080)

I noticed that their (Unladen Swallow) progress seemed to have stopped, is there any official announcement?

Unladen Swallow is an ex-parrot. [google.com] . "Jeffrey and I have been pulled on to other projects of higher importance to Google.", writes the former project lead.

LuaJIT (0)

Anonymous Coward | more than 3 years ago | (#37083002)

Let's see some comparisons to real JIT compilation, LuaJIT.

Re:LuaJIT (0)

Anonymous Coward | more than 3 years ago | (#37086952)

Luajit is absolutely great, and Mike Pall (its creator) is a bad ass programmer.
But Lua is simpler language, much more than python or javascript.
It has a small core, only one container data type and no batteries included. Hence it's easier to optimize.
Even Mike Pall recognized that doing the same thing for python would take years, not months as luajit. And this approach wouldn't have all the other advantages of the pypy project, which is a framework for writing dynamic language virtual machines with built in just-in-time compilers.

And now for ruby please (1)

swarsron (612788) | more than 3 years ago | (#37083926)

And now for ruby please. I love ruby, but the performance issues drive me crazy sometimes.

Re:And now for ruby please (0)

Anonymous Coward | more than 3 years ago | (#37088534)

Write a Ruby interpreter in RPython. You get the JIT for free.

Re:And now for ruby please (1)

Moldiver (1343577) | more than 3 years ago | (#37090048)

Get a Mac and have a look at MacRuby. Near Obj-C Performance and JIT/AOT through LLVM.

Horrible Name (1)

Digital Mage (124845) | more than 3 years ago | (#37090694)

I'm sorry...I don't want to see how it looks or play with your PyPy. I will most definitely NOT click on your online demo to show your "Assembler".

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?