Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyston v2: Faster Python

blog.pyston.org

Post reply on HN
Print view View original

201–210 of 211 posts

Re: Pyston v2: Faster Python

#201

Post by globular-toast »

theamk wrote: post #199
globular-toast wrote: post #179

Earlier quoted context omitted.

> I guess it means no one should be touching the file, as they haven't even granted access to run it. Since when does someone need to explicitly grant you permission to run a program on your own computer?

Running is probably ok, but giving to others? I am not sure. Those limitations existed since before the computer time, when the copyright law was passed. For example, even you own a book, there are certain things you can not do, like duplicate it and sell copies. In case of software, here is how the law works [0] > When you make a creative work (which includes code), the work is under exclusive copyright by default.…

Yeah, you won't be able to distribute it, but running it should be fine (unless you want to consider copying it from disk to memory as copying, of course).

Re: Pyston v2: Faster Python

#202

Post by willseth »

musicale wrote: post #132
willseth wrote: post #57

Earlier quoted context omitted.

A different perspective is that Python leadership has been overwhelmed addressing the concerns of the enormous and growing Python community, for whom generally performance is not yet the primary concern - believe it or not. It's probably fair to suggest PSF has stumbled in executing some of their goals, most notably and publicly the transition to v3, but overall it seems like the general Python community is most inte…

> It's probably fair to suggest PSF has stumbled in executing some of their goals, most notably and publicly the transition to v3 In a recent post linked on HN, Steve Yegge basically nailed it: > How much new software was written in something other than Python, which might have been written in Python if Guido hadn’t burned everyone’s house down? It’s hard to say, but I can tell you, it hasn’t been good for Python. It…

I did RTFA, but I haven't been on the Python scene long enough to have a truly educated opinion about the transition to v3. It's not unusual for a language to make breaking changes in early versions. What happens when you realize you need to do it late in the game? Tough call. I think it's probably impossible to know whether cost of breaking changes in the short term (people leaving Python for Go, etc.) was justified relative to the cost of a crufty and inadequate Python in the future (people leaving Python for Go, etc.). I'm generally sympathetic, but I'm glad I didn't get into Python until the transition was well underway.

Re: Pyston v2: Faster Python

#203

Post by throwaway894345 »

sk2020 wrote: post #196
throwaway894345 wrote: post #164

Earlier quoted context omitted.

That’s quite a rant with a lot of assumptions. Just about every library has a better API than matplotlib or pandas. Requests has a pretty good API IMO. The team who was responsible for the slow endpoint did investigate dask and alternatives, and they probably will end up on something like spark because they didn’t feel like they have better options. Maybe our team is just stupid and Python isn’t for mere mortals, I d…

I would certainly hope a minimal HTTP library would be simpler than a suite of functions to manipulate and plot tabular data. “My application is slow, the language sucks!” Doesn’t indicate a very serious investigation into the problem.

> I would certainly hope a minimal HTTP library would be simpler than a suite of functions to manipulate and plot tabular data.

HTTP is pretty complex, but that's neither here nor there. The relevant bit is that there is no domain for which guessing caller intent based on reflection over argument types is appropriate.

> “My application is slow, the language sucks!” Doesn’t indicate a very serious investigation into the problem.

I was pretty explicit above and elsewhere in this thread about why Python's performance is miserable; I'm not sure why you would invoke such a poorly constructed straw man when everyone can look upthread and see my actual arguments.

Re: Pyston v2: Faster Python

#205

Post by rurban »

jonstewart wrote: post #194

What is meant by “quickening”?

The paper is gone. Maybe someone has a link.

Looks like inline caching of some specific ops with certain types. Some arith and call ops are optimized this way.

It also looks like dynasm was later replaced by the much slower llvm, so it needs heavy warmup.

Re: Pyston v2: Faster Python

#206

Post by kzrdude »

rurban wrote: post #205
jonstewart wrote: post #194

What is meant by “quickening”?

The paper is gone. Maybe someone has a link. Looks like inline caching of some specific ops with certain types. Some arith and call ops are optimized this way. It also looks like dynasm was later replaced by the much slower llvm, so it needs heavy warmup.

I wonder if it's similar to Python 3.x's opcache for Load global and load attr? It would make a lot of sense to generalize those.

Re: Pyston v2: Faster Python

#207

Post by kzrdude »

oscargrouch wrote: post #124

Funny their choice over luajit's Dynasm, when you have something like Turbofan laying around. The V8 Javascript interpreter can generate machine code dinamically targetting the host arch for each bytecode instruction.. You can define the target assembly directly in C++ without resorting to any specific machine code. Maybe complexity or because they wanted to stick to C?

Would it be easy to apply turbofan to Python? Do you have any details?

Re: Pyston v2: Faster Python

#208

Post by rurban »

oscargrouch wrote: post #124

Funny their choice over luajit's Dynasm, when you have something like Turbofan laying around. The V8 Javascript interpreter can generate machine code dinamically targetting the host arch for each bytecode instruction.. You can define the target assembly directly in C++ without resorting to any specific machine code. Maybe complexity or because they wanted to stick to C?

They replaced dynasm in 2014 with llvm. Then there was no other good jit around. llvm is certainly not good either, but for specific workloads in companies it's doable, for benchmarks or short scripts not.

Re: Pyston v2: Faster Python

#209

Post by amkkma »

rwallace wrote: post #193
semi-extrinsic wrote: post #172

Earlier quoted context omitted.

My gripe with Julia etc. as replacements, is that Python is duct tape. I don't need fast duct tape, I need duct tape that is understood and used by essentially everyone I work with, and that has native, fast handling of large amounts of data (NumPy, Pandas). Good user experience as duct tape. From my perspective Julia is sacrifising some amount of "duct tape UX" to gain speed, and that's the wrong direction. Whenever…

> From my perspective Julia is sacrifising some amount of "duct tape UX" to gain speed, and that's the wrong direction. What particular language features of Julia make that trade-off? (Not a rhetorical question, I'm not disagreeing with you, just curious; I'm familiar with Python, not really familiar with Julia.)

Probably the usual complaints about package load and compilation time.

These aren't fundamental issues with the language and will be solved by tiered compilation (there's already an interpreter mode, just have to integrate that with normal use), separate compilation and incremental sysimage creation which works with the package manager.

Re: Pyston v2: Faster Python

#210

Post by mlyle »

hhas01 wrote: post #45
qorrect wrote: post #6

Earlier quoted context omitted.

I use python because of Numpy, Scikit and Tensorflow. I don't know of any other languages with libraries as productive as these, so speeding these apps up is a big win for a lot of people. Also 20% is huge, I look forward to trying it!

20% faster is nothing. You want at least a magnitude faster to justify the cost and risk of switching. The Python language is already 30 years old, and it wasn’t even the cutting-edge in imperative language design ( Smalltalk, Lisp ) back then. It’s positively antiquated now. I’ve never understood this tunnel-vision obsession with endlessly chasing ever-diminishing returns. It’s Zawinski's Law of Software by way of G…

> 20% faster is nothing. You want at least a magnitude faster to justify the cost and risk of switching.

Eh. If newer versions of cpython end up 20% faster, eventually most things will end up running on those newer versions. It may take years for almost everything to drift to newer versions, but there's a noticeable performance benefit we all realize over time.

> Learn the lessons from both the good and bad of what’s been done before, and move on. A better long-term answer would be to design a much faster, more efficient language for running Numpy, Scikit, and Tensorflow, then port those libraries over to that. If that language turns out to be good for other things too, then great. If not, let a thousand flowers bloom.

Python's great at running numpy, scikit, and tensorflow. It's not the bottleneck, because these are largely native libraries-- achieving something "much faster" and "more efficient" for this are doubtful.

The benefits of Python are that it A) has a huge ecosystem, B) it's relatively polished and expedient to write code in, and C) there's a ton of people who know it. These are not easy things to create somewhere else, and there's no guarantee that the set of tradeoffs you choose will leave you in a better place afterwards.

The biggest downside of Python is that if you want to get a lot of concurrency or performance for Python code (instead of things like numpy, scikit, and tensorflow), you get pushed into the edges of the Python ecosystem, where you only get a portion of A's advantage (but still largely realize B & C).

Post reply on HN