See the PyPy JIT In Action

Go Pypy! by Anonymous Coward · 2011-08-13 11:40 · Score: 4, Informative

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! by AwesomeMcgee · 2011-08-13 12:10 · Score: 1

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! by TheStonepedo · 2011-08-13 12:24 · Score: 1

Thanks anon!
Somebody should mod this coward up.

--
I'll be your candy shop of infinite deliciousity if you'll be my discotheque of endless rump-shaking.
Re:Go Pypy! by icebraining · 2011-08-13 12:30 · Score: 1

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.

--
Dilbert RSS feed
Re:Go Pypy! by H0p313ss · 2011-08-13 14:25 · Score: 2, Insightful

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...)

--
XML is a known as a key material required to create SMD: Software of Mass Destruction
Re:Go Pypy! by Anonymous Coward · 2011-08-13 14:59 · Score: 3, Insightful

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! by buchner.johannes · 2011-08-13 15:22 · Score: 2

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

--
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Re:Go Pypy! by OeLeWaPpErKe · 2011-08-13 15:36 · Score: 2, Insightful

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! by AtlantaSteve · 2011-08-13 15:49 · Score: 1

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! by Tumbleweed · 2011-08-13 17:13 · Score: 2

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! by chromatic · 2011-08-13 18:18 · Score: 1

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

... until you do IO.

--
how to invest, a novice's guide
Re:Go Pypy! by OeLeWaPpErKe · 2011-08-13 19:48 · Score: 1

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! by OeLeWaPpErKe · 2011-08-13 19:58 · Score: 1

Yes, but even then you can still group them into large chunks, instead of small allocations.
Re:Go Pypy! by smallfries · 2011-08-13 20:41 · Score: 1

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?

--
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
Re:Go Pypy! by ThePhilips · 2011-08-13 23:39 · Score: 2

[...] 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.

--
All hope abandon ye who enter here.
Re:Go Pypy! by KDR_11k · 2011-08-13 23:55 · Score: 1

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

--
Justice is the sheep getting arrested while an impartial judge declares the vote void.
Re:Go Pypy! by KDR_11k · 2011-08-14 00:04 · Score: 1

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.

--
Justice is the sheep getting arrested while an impartial judge declares the vote void.
Re:Go Pypy! by Ragzouken · 2011-08-14 00:13 · Score: 1

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! by Requiem18th · 2011-08-14 01:52 · Score: 2

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.

--
But... the future refused to change.
Re:Go Pypy! by sgt+scrub · 2011-08-14 03:57 · Score: 1

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

--
Having to work for a living is the root of all evil.
Re:Go Pypy! by shutdown+-p+now · 2011-08-14 06:43 · Score: 1

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! by thePuck77 · 2011-08-14 07:39 · Score: 1

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.

--
"We live as though the world were as it should be, to show it what it can be." - Joss Whedon via Angel
Re:Go Pypy! by thePuck77 · 2011-08-14 07:49 · Score: 1

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).

--
"We live as though the world were as it should be, to show it what it can be." - Joss Whedon via Angel
Re:Go Pypy! by thePuck77 · 2011-08-14 08:04 · Score: 1

Ding ding ding! We have a winner!

--
"We live as though the world were as it should be, to show it what it can be." - Joss Whedon via Angel
Re:Go Pypy! by rwa2 · 2011-08-14 13:27 · Score: 1

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.
Re:Go Pypy! by Requiem18th · 2011-08-15 01:32 · Score: 1

Self, Io-language, Smalltalk, Ruby and of course Python or even Lisp, but also Java, C# or Vala if you want static typing.
You mean something supported on todays browsers? Yes, Javascript. But as long as you are reinventing the browser you can always pick a better scripting language.

--
But... the future refused to change.
Re:Go Pypy! by thePuck77 · 2011-08-15 02:02 · Score: 1

Well, if I have the luxury of reinventing the browser and choosing a new standard, I would vote for Smalltalk (I would say Lisp, but I foresee forcing too many square pegs in round holes to go there). But right now we are stuck with JS or running things through the Java JIT.

--
"We live as though the world were as it should be, to show it what it can be." - Joss Whedon via Angel
Re:Go Pypy! by smallfries · 2011-08-16 06:07 · Score: 1

You've missed the point: yes it is easy to do this dynamically at the cost of performance. The comment was in response to the claim that doing it statically is easy. It's not easy to analyse this statically, but when it can be done the performance increase is large. One optimisation that it allows straight away is unboxing which can easily increase the performance of numerical code by an order of magnitude.

--
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php

And by see you mean by Anonymous Coward · 2011-08-13 11:40 · Score: 3, Funny

the connection has timed out

Python, the new Java

Re:And their gone by jonahbron · 2011-08-13 11:43 · Score: 1

I think you mean "And they're gone"

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

...whatever that is...

Re:And their gone by kiddygrinder · 2011-08-13 11:48 · Score: 1

plenty of high traffic sites use python

--
This is a joke. I am joking. Joke joke joke.

Woo hoo! by 93+Escort+Wagon · 2011-08-13 11:53 · Score: 3, Informative

I'm glad to see it scales well!

--
#DeleteChrome

Re:LLVM? by rg3 · 2011-08-13 12:00 · Score: 2

No, that was Unladen Swallow.

Re:LLVM? by MtHuurne · 2011-08-13 12:01 · Score: 1

No, that is Unladen Swallow.

Re:Not a big fan of Python, but... by icebraining · 2011-08-13 12:38 · Score: 1

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.

--
Dilbert RSS feed

Re:Another example of Open Source showing immaturi by thetoadwarrior · 2011-08-13 12:48 · Score: 1

So what is named after a penis?

Re:LLVM? by Millennium · 2011-08-13 12:57 · Score: 1

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

Re:Another example of Open Source showing immaturi by Anonymous Coward · 2011-08-13 12:58 · Score: 1

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

Re:Not a big fan of Python, but... by Mitchell314 · 2011-08-13 13:09 · Score: 1

I think javac is a java program.

--
I read TFA and all I got was this lousy cookie

Re:The difference between Python and Ruby devs. by Anonymous Coward · 2011-08-13 13:13 · Score: 2, Interesting

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:Not a big fan of Python, but... by Anonymous Coward · 2011-08-13 13:33 · Score: 1

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").

Re:Another example of Open Source showing immaturi by whoop · 2011-08-13 14:05 · Score: 1

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

Re:And their gone by sycodon · 2011-08-13 14:05 · Score: 1

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

--
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.

Quora by Anonymous Coward · 2011-08-13 14:09 · Score: 2, Interesting

quora.com is now running on PyPy.

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

Faster than C? by lee1 · 2011-08-13 16:50 · Score: 3, Informative

Not just faster than CPython, but faster than C 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. But when they get that to work, wow.

Re:Faster than C? by whiteboy86 · 2011-08-13 19:26 · Score: 1

Dream on, its like those 'over unity' energy source claims.
Re:Faster than C? by nzac · 2011-08-13 21:59 · Score: 1

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? by lee1 · 2011-08-14 02:55 · Score: 1

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? by complex_pi · 2011-08-14 02:59 · Score: 1

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.
Re:Faster than C? by nzac · 2011-08-14 11:02 · Score: 1

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? by m50d · 2011-08-14 23:38 · Score: 1

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.

--
I am trolling
Re:Faster than C? by nzac · 2011-08-15 00:27 · Score: 1

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/
http://bstring.sourceforge.net/features.html
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? by m50d · 2011-08-15 02:03 · Score: 1

We're talking C, not C++, so boost is irrelevant. Sure sprintf is big and flexible, but so is python's % operator; the comparison is a fair one, standard language feature to standard language feature. You may well have a faster string library, but using nonstandard libraries has its own problems - you now have two different ways to format your strings, and if you try and do the same thing with some other part of your program (say introduce a nonstandard faster networking library) then whoops, your two nonstandard libraries don't work with each other and you're stuffed.
Of course it's a small, arbitrary comparison, but it's a fair one, with the same rules for both sides - we're talking about the natural, obvious, standard way of writing the same operation in each language. If you want to make it a C victory on the same terms I'd be interested to see whether ICC's whole-program optimization is able to push the constant string down through the standard library.

--
I am trolling
Re:Faster than C? by nzac · 2011-08-15 18:13 · Score: 1

We are talking about pypy being better than native programs so if C++ benchmarks are also valid. If this is just a contest to convert an integer to a string and write it to arbitrary memory as fast as you can and not factoring in pythons order of magnitude(s) greater expressiveness and readability. You are taking a standard data type and returning an array of standard data there no issues with other libraries. Using a copy and pasted integer to string function (itoa(...)) that has some checking of valid inputs this will do the job in less than percent of the time under -O3 (no optimization is barely faster so an optimized sprintf could be faster). My CPU is not as good as his.
int main() {
int i = 0;
int ilt=0;
int val=0;
char x[44];
char buffer[15];
for (i = 0; i less than 10000000; i++) {
ilt=0;val=0;
itoa (i,buffer,10);
while (x[ilt]){
x[ilt]=buffer[ilt];
ilt++;
}
x[ilt]=" ";
val=ilt;
ilt=0;
while (x[ilt]){
x[ilt+val]=buffer[ilt];
ilt++;
}
x[ilt+val]="\0";
}
}
I think that still pretty impressive of pypy but there are sill corners that could be cut for the c code. For easy native speed string manipulation C++ is far superior to C for writing and reading of code operator overloading, classes and pretty much half of the extra of it this allow people far more skilled than myself to optimize the program.

Of course it's a small, arbitrary comparison, but it's a fair one, with the same rules for both sides - we're talking about the natural, obvious, standard way of writing the same operation in each language.
Not really the C code from his example was just as fast under O1 yet he cranked it up to O3/4 and says it's a fully optermised benchmark. The only reason to code this in C is if you want peak performance if you want to use similar language to python you would use C++ with the string libraries. C's lack of objects makes dealing with strings a verbose task that there is no good reason to undertake it for general use and therefore there are no better solutions.

PyPy solves a very hard problem, but is still slow by Animats · 2011-08-13 16:51 · Score: 4, Informative

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:Another example of Open Source showing immaturi by JonySuede · 2011-08-13 17:33 · Score: 2

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

--
Jehovah be praised, Oracle was not selected

Re:PyPy solves a very hard problem, but is still s by jgrahn · 2011-08-13 18:09 · Score: 1

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 by smallfries · 2011-08-13 20:48 · Score: 1

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.

--
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php

Re:PyPy solves a very hard problem, but is still s by smallfries · 2011-08-13 20:51 · Score: 1

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.)

--
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php

And now for ruby please by swarsron · 2011-08-13 21:54 · Score: 1

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

Re:And now for ruby please by Moldiver · 2011-08-14 12:27 · Score: 1

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

Re:PyPy solves a very hard problem, but is still s by Animats · 2011-08-14 04:07 · Score: 1

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

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

Horrible Name by Digital+Mage · 2011-08-14 14:33 · Score: 1

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".

Re:PyPy solves a very hard problem, but is still s by dkf · 2011-08-14 19:54 · Score: 1

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.

--
"Little does he know, but there is no 'I' in 'Idiot'!"

Re:PyPy solves a very hard problem, but is still s by smallfries · 2011-08-15 01:32 · Score: 1

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

--
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php

Re:PyPy solves a very hard problem, but is still s by White+Flame · 2011-08-15 12:59 · Score: 1

Lisp yawns at how easily impressed you are.

I don't see this working by Lobais · 2011-08-26 04:56 · Score: 1

Seams boxing isn't too much of an issue for vanilla python when summing 1000,000 integers.

$ pypy -m timeit "sum(range(1000000))"
10 loops, best of 3: 55.2 msec per loop
$ python -m timeit "sum(range(1000000))"
10 loops, best of 3: 71.5 msec per loop
$ python3 -m timeit "sum(range(1000000))"
10 loops, best of 3: 62.7 msec per loop
$ python -m timeit "sum(xrange(1000000))"
10 loops, best of 3: 26.6 msec per loop
$ pypy -m timeit "sum(xrange(1000000))"
10 loops, best of 3: 132 msec per loop

$ pypy --version
Python 2.7.1 (?, May 02 2011, 19:05:35)
[PyPy 1.5.0-alpha0 with GCC 4.6.0]
$ python --version
Python 2.7.1
$ python3 --version
Python 3.2

67 of 109 comments (clear)