Hacker News Reader

Comment by hackermom | Hacker News Reader

Wholeheartedly without trolling, but admittedly with some bitterness, and with much experience in Python, Perl, PHP, Java, C/++ and more, another thing that Python will fix for you is the problem of having a too fast processor on your deployment platform: Python effectively eliminates this problem in most cases, way better than most other languages will. There's always another side of every coin, and it shouldn't ever be ignored.

View on HN

Bear in mind that this is only applicable if your code is very CPU-bound. If it's IO-bound as many applications are these days, then this is for all intents and purposes a non-issue.

It's been a non-issue for almost a decade!

This is a non-statement -- if the code is IO-bound, then of course CPU performance is not a problem (except for things like, say, power usage, but we'll ignore that). The "power" of Python is to make code that should be IO-bound CPU-bound.

Speaking as someone who loves Python and uses it all the time, but has spent a lot of time learning to love Cython in recent months. A nice feature of Cython (psychologically speaking, at least) that is missing in Python is the power to say that dammit, certain constants are constant, will never be changed, and can be inlined instead of having a hash table lookup every single time.

I think it's more accurate to say that it's a truism. Unfortunately, it's one that a lot of people forget.

> the problem of having a too fast processor on your deployment platform

The sarcasm here is unwarranted, as is basically your entire paragraph. Why not just say: Python is slow ?

Because then it would look as if she were off-topic.

Python has never; and probably never will claim to be the fastest language in the stable. The tradeoff made is processor time, versus developer time - one is cheap, one is not.

Should, and can Python be faster without sacrificing the speed of the programmer (including extension authors)? Yes, it can and will be, but never at the cost of productivity.

Should, and can Python be faster without sacrificing the speed of the programmer (including extension authors)? Yes, it can and will be, but never at the cost of productivity.

That this is a trade-off at all is a woefully outdated idea.

Ironic, because I'm only 30. It's not outdated at all - take for example, the GIL - sure, get rid of it, and put in granular locking. You've now actively harmed the lives of every C extension author and maintainer out there, and slowed down single threaded performance.

Sure; it's "easy" - but the cure can be worse than the disease for most of the python-using population. It's all a series of tradeoffs and compromises - in time, things like pypy and unladen swallow will change this (for python) but given both of those are pretty bleeding edge, I'd argue my initial point still stands.

Funny, but lots of other dynamic langs interface with C without such a badly designed GIL. The GIL actually proves my point. The fact that people will excuse such poor performance in a dynamic lang is a matter of misplaced expectation. This was a clever hack in the beginning, but proved to be a major design flaw going forward. A performance hit of over 3 orders of magnitude is not excusable for any language, "scripting" or otherwise.

Yes, it was a clever hack in the beginning - which is what counted. Given that Python's implementation (CPython, with a GIL) was started in December of 1989 (http://python-history.blogspot.com/2009/01/brief-timeline-of...) I'd say that it worked fabulously at the time, and pretty much until multicore/multiprocessor architectures really became the topic du-jour.

Think about that; CPython's internal are old - sure, they've changed and been cleaned up and fixed up here and there, but it's still old. Obviously if it was written today, it might be done differently knowing what we know now.

So, yeah - it is excusable, given that it meets the original design goals of making C extensions dirt simply to write (really, they are dirt simple) and making the common, single threaded/single processor use case fast "enough".

Given the hindsight everyone has now - yeah, the GIL as it exists today is grossly suboptimal, and I don't know of anyone of rational mind or body who doesn't want it to go the way of the dodo, or at least be replaced with a cleaner, simpler and faster implementation. The latter is in progress in Python 3 - the former is a lot more difficult despite a lot of hand waving from non-committers and armchair interpreter designers.

Python's performance can (and is, and will) be improved over time, but as I said originally, it was never advertised as "the fastest" or "the most concurrent" language, those two things have never been a core "feature" of the language.

I'd say that it worked fabulously at the time

Which is what I also implied. C extensions are simple to use for Visualworks Smalltalk, whose development goes back in direct lineage to 1989. Again, why is the GIL such a problem?

Can you expand on this, please?

see for example:

http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

Reply on news.ycombinator.com