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

Yes, Python is Slow, and I Don’t Care

hackernoon.com

Post reply on HN
Print view View original

151–160 of 206 posts

Re: Yes, Python is Slow, and I Don’t Care

#151

Post by mark-r »

hellofunk wrote: post #104
Jtsummers wrote: post #98

Earlier quoted context omitted.

http://www.adaic.org/resources/add_content/standards/05aarm/... Compile-time and run-time floating point numbers constrained by precision and range. It's been a long time so I'm just going to include the examples in that document: type Coefficient is digits 10 range -1.0 .. 1.0; type Real is digits 8; type Mass is digits 7 range 0.0 .. 1.0E35; subtype Probability is Real range 0.0 .. 1.0; These will be checked (to th…

Cool, but I don't know much about Ada, and would like to see an example for a statically-typed "range checker" in a more mainstream language used actively today. C++ templates can do a lot of magical stuff at compile time but such techniques are well beyond the reach of most developers. I can't think of any typed language I've used or seen in active modern professional work where you could validate a value as part of…

Pascal has integer range types, but Pascal hasn't been mainstream for a long time now.

Re: Yes, Python is Slow, and I Don’t Care

#152

Post by traverseda »

jerf wrote: post #55
traverseda wrote: post #22

There's are still some big gains python could make, if python implementations were better. Micropython is equivalent to a real-time cooperative-multitasking OS. If it had ~~better~~ support for things like cffi, you could implement posix on top of it. I can imagine a laptop that runs gnu+python in the next few years. That's a whole new usecase, simply because that implementation uses a lot less ram. What usecases wou…

"There's are still some big gains python could make, if python implementations were better." At this point, I would find it far easier to believe that you are underestimating the difficulty involved in what it takes to speed up Python than that there are enormous gains yet to be had in speeding up Python. I suspect JS has had more optimization effort expended overall, but Python has still had a ton of work by lots of…

I consider "python implementations being better" to be some simple things.

* pypy-level performance by default

* Much faster startup times (I'm looking at you namedTuple)

* Better libraries for specific use-cases, like interacting with opengl

* Rpython actually being documented so I can write library code in it

I'd also really like to see good sandboxing and fast-enough object sharing.

Those are the kinds of things I think can open up whole new market-segments. And python being used by more market-segments means more support for python.

Re: Yes, Python is Slow, and I Don’t Care

#153

Post by dragonwriter »

hellofunk wrote: post #78
rockostrich wrote: post #34

Earlier quoted context omitted.

But with a statically typed language, you don't need to go through that code -> launch -> test cycle as often because everything is type-safe.

You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Typing has its place but the idea that it catches all bugs at compile time certainly isn't true; the cycle of running the app itself, running its tests, is just as important for statically-typed code as dynamically typed. Languages that have a sophisticated contract syste…

> You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that.

Sure, it can; many common numeric types include specific ranges, the fact that the range 0-1 doesn't match any common floating point type doesn't mean that it isn't one that could be a type.

Re: Yes, Python is Slow, and I Don’t Care

#154

Post by joshuamorton »

AstralStorm wrote: post #149
mattkrause wrote: post #108

Earlier quoted context omitted.

You're violently agreeing with each other. Python itself can be pretty slow. Doing image processing on data stored as list-of-lists-of-integers would be brutally slow. On the other hand, numpy is an import away, and it can be quite fast, especially if it's been built with an optimized BLAS/ATLAS, etc.

By blazingly fast you mean 100x slower than C++ equivalent and only 20x slower is you're very careful to avoid accidental copies. For reference, MATLAB is about 30x slower with no special care. Pure Java on Hotspot was 5x slower except it dies on big data input due to very slow GC and goes to 50x slow. Source: handled big audio data from hdf5 database, gigabytes sized. C++ equivalent had no vectorization or magic BLA…

As I'll often say to these comments, then you're doing things wrong. Numpy code can be written to never leave the numpy sandbox, and at that point it should be as fast or faster than naive c++ (because you'll be getting SSE and stuff for free).

There's a reason almost all deep learning is done in python.

Re: Yes, Python is Slow, and I Don’t Care

#155

Post by aeorgnoieang »

jayflux wrote: post #14

I get the point this guy is making, but if you need something parallel for a cpu bound task, throwing more hardware at the problem isn't the most efficient solution if you can just use more cores. For example adding another quad core when the first cpu is only using one core anyway is inefficient and expensive. Right tool for the right job I suppose.

The point is that (modifying existing code or writing new code to) "just use more cores" may be less efficient, for the business or organization that is employing the programmer, given that programmer salaries, over even a fairly short amount of time, can be more expensive than hardware.

Re: Yes, Python is Slow, and I Don’t Care

#156

Post by Someone »

hellofunk wrote: post #104
Jtsummers wrote: post #98

Earlier quoted context omitted.

http://www.adaic.org/resources/add_content/standards/05aarm/... Compile-time and run-time floating point numbers constrained by precision and range. It's been a long time so I'm just going to include the examples in that document: type Coefficient is digits 10 range -1.0 .. 1.0; type Real is digits 8; type Mass is digits 7 range 0.0 .. 1.0E35; subtype Probability is Real range 0.0 .. 1.0; These will be checked (to th…

Cool, but I don't know much about Ada, and would like to see an example for a statically-typed "range checker" in a more mainstream language used actively today. C++ templates can do a lot of magical stuff at compile time but such techniques are well beyond the reach of most developers. I can't think of any typed language I've used or seen in active modern professional work where you could validate a value as part of…

I think you can get quite far in C++ with a class that has a constexpr constructor taking a double that checks for range, and (quite a few) operator overloads that allow one to do the normal operations on such quantities.

Re: Yes, Python is Slow, and I Don’t Care

#157

Post by kazinator »

hellofunk wrote: post #78
rockostrich wrote: post #34

Earlier quoted context omitted.

But with a statically typed language, you don't need to go through that code -> launch -> test cycle as often because everything is type-safe.

You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Typing has its place but the idea that it catches all bugs at compile time certainly isn't true; the cycle of running the app itself, running its tests, is just as important for statically-typed code as dynamically typed. Languages that have a sophisticated contract syste…

> A type can't tell you that.

Yes, it can! --- but you don't necessarily want to confound your program with such a thing.

The old adage about the cure being worse than the disease applies.

Re: Yes, Python is Slow, and I Don’t Care

#158

Post by nerdwaller »

dom96 wrote: post #42
nerdwaller wrote: post #33

Earlier quoted context omitted.

Have you checked out MyPy and the optional type hinting? I've been going that route in my python recently and been liking the both/and of having an optional type checker.

I have, and I do like that Python is heading in this direction. But this feature does still feel half-baked to me, the error messages are often confusing and I do recall running into a few bugs along the way. I'm also not certain that the type hinting will ever be 100%, the dynamic nature of Python seems to prevent that. This could end up giving some people a false sense of correctness.

The _getting started_ part could certainly be a bit smoother, I have had a few issues as well. Generally speaking I think for in-house things you can probably alleviate a bit of the possible dynamic issues that you mention - just by discouraging too much meta-ness.

Re: Yes, Python is Slow, and I Don’t Care

#159

Post by hellofunk »

dragonwriter wrote: post #153
hellofunk wrote: post #78

Earlier quoted context omitted.

You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Typing has its place but the idea that it catches all bugs at compile time certainly isn't true; the cycle of running the app itself, running its tests, is just as important for statically-typed code as dynamically typed. Languages that have a sophisticated contract syste…

> You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Sure, it can; many common numeric types include specific ranges, the fact that the range 0-1 doesn't match any common floating point type doesn't mean that it isn't one that could be a type.

> many common numeric types include specific ranges

Can you give me a mainstream language example?

Re: Yes, Python is Slow, and I Don’t Care

#160

Post by hellofunk »

kazinator wrote: post #157
hellofunk wrote: post #78

Earlier quoted context omitted.

You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Typing has its place but the idea that it catches all bugs at compile time certainly isn't true; the cycle of running the app itself, running its tests, is just as important for statically-typed code as dynamically typed. Languages that have a sophisticated contract syste…

> A type can't tell you that. Yes, it can! --- but you don't necessarily want to confound your program with such a thing. The old adage about the cure being worse than the disease applies.

> Yes, it can!

Ok, how? Other than an Ada example, or dependently-typed languages that aren't use in production, can you offer an example?

Post reply on HN