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

Python’s Weak Performance Matters

metarabbit.wordpress.com

Post reply on HN
Print view View original

321–330 of 336 posts

Re: Python’s Weak Performance Matters

#321

Post by dagw »

blub wrote: post #318
brians wrote: post #279

Earlier quoted context omitted.

Yeah. Speed is the dominant cost in software, but other industries treat other costs similarly. To pick another darling, look at Tesla: the Roadster is expensive, flammable, suitable only for enthusiasts. The S is generally useful, but too expansive. Still a narrow market. The E is their first general purpose product. That’s normal. Same deal with Apple II, Mac, iPhone. Same deal with ether, coarse general anesthetic…

All of the things you mentioned worked and had good enough performance. There was no crappy version of the iPhone which ran out of battery in 1h and took seconds to refresh when scrolling. So obviously they thought about the performance aspect from the start.

There was no crappy version of the iPhone which ran out of battery in 1h and took seconds to refresh when scrolling.

I'm pretty sure there probably was. They where just smart enough to make sure the only people that saw that version where a handful of engineers in their R&D lab.

Re: Python’s Weak Performance Matters

#322

Post by zild3d »

blub wrote: post #228
lmm wrote: post #203

Earlier quoted context omitted.

> It is a failure of our community that we allow languages to proliferate while remaining slow. This is bad because allowing slow tools to become popular means people create slow things, which wastes other peoples time and energy. Make it work, then make it work right, then make it work fast. I mean yes, a lot of things are slower than they should be, but the level of outright correctness bugs in software today is mi…

This "make it work" adage makes no sense at all when scrutinized. Does anyone believe that other industries think like that? First let's invent a washing machine that washes, but occasionally sets clothes on fire and takes 24h for a washing cycle. Then we'll redesign it so it doesn't set things on fire, and finally redesign it yet again to finish in 2h. It's incredibly wasteful. For any complex project, making it wor…

Yes. It's the prototyping phase. Medicine, hardware, even food. Cliff made his energy bars "work" first in his kitchen, then started to figure out how to make them scalable and optimized for taste, etc.

Any hardware startup does the same. Get a giant, hulky prototype going, with shotty wiring, way too much weight, and get it working. This make it work first adage is because you don't know what the final product/project will need to be (e.g. do it in python and then figure out how to make it better)

Re: Python’s Weak Performance Matters

#323

Post by newen »

rhaps0dy wrote: post #316
ChrisRackauckas wrote: post #288

Earlier quoted context omitted.

I'm using Julia and loving it. I've built a bunch of differential equation solvers which routinely outperform the classic C++/Fortran codes. I started out without "software development" experience but Julia and its community got me up to speed and helped me build something quite unique. Now Julia is the only language that has the numerical libraries I need to do my research. In fact, the whole library story in Python…

>If you're doing something which is actually new, like PhD methods research, you need to be writing a lot of stuff from scratch. Sometimes you also reuse a lot of stuff, it depends. For machine learning in particular, almost everything uses some sort of gradient-based optimisation algorithm. In these cases, it is very useful to have an automatic differentiation library. My coworker said Julia has about 3, IIRC, and u…

> until an amalgamation of them is merged into the standard library Julia isn't completely ready

That doesn't quite make sense. I'm sure there are a few more autodiff libraries in Julia than 3. You would just use the one that fits your use case.

PS. Ohh re-reading your comment, you want an autodiff library in Julia's standard library. That is very unlikely to happen since it's not (very) hard to cook up an autodiff library and autodiff is not widely used. Julia is not like Matlab, where you have to have everything in the standard library.

Re: Python’s Weak Performance Matters

#324

Post by blub »

zild3d wrote: post #322
blub wrote: post #228

Earlier quoted context omitted.

This "make it work" adage makes no sense at all when scrutinized. Does anyone believe that other industries think like that? First let's invent a washing machine that washes, but occasionally sets clothes on fire and takes 24h for a washing cycle. Then we'll redesign it so it doesn't set things on fire, and finally redesign it yet again to finish in 2h. It's incredibly wasteful. For any complex project, making it wor…

Yes. It's the prototyping phase. Medicine, hardware, even food. Cliff made his energy bars "work" first in his kitchen, then started to figure out how to make them scalable and optimized for taste, etc. Any hardware startup does the same. Get a giant, hulky prototype going, with shotty wiring, way too much weight, and get it working. This make it work first adage is because you don't know what the final product/proje…

Ah food. I believe Soylent was experimenting with this idea of make it work and then make it work right, which resulted in a lot of entertainment for those that read the toilet stories of Soylent customers.

I don't see why there has to be a hard cut between make it work and make it work right or fast in prototyping. With more thought, perhaps the product can already be largely right and fast enough and also easily improvable.

I can't help but look at this saying as an excuse to get something done fast with the hope it can be improved later. This is not a general truth.

Re: Python’s Weak Performance Matters

#325

Post by empthought »

bzbarsky wrote: post #300
empthought wrote: post #298

Earlier quoted context omitted.

> Yes, my point is that function scoping can hardly be described as "makes sense all the time". Block and function scoping both "make sense all the time." Whether or not you personally are accustomed to a language's design decisions does not have any bearing on whether or not those decisions "make sense." In the particular case you cited, of course it is natural that `foo` is in scope outside of the loop; it appears…

The context is that we're talking about people picking up the language for the first time, coming from other languages. What matters is whether the scoping rules make sense to such people. For that, it matters whether they're coming from another function-scoped language (or are familiar with one), and whether they're used to having their variable declarations being obvious or not. For me, when I was first learning Py…

Python is and always has been designed to be an introductory programming language, so your criticism does not apply in the case of this design intent. More people learn Python first than learn another language first. Having seen beginning programmers learn Python, I can say this is an utter nonissue to them.

For the case of experienced programmers, the behavior is consistent and simple. In what way does this not "make sense?" Does Haskell's normal order evaluation not "make sense?" Does Ruby's optional parentheses for method calls not "make sense?" Does a regular expression literal syntax not "make sense?" Does JSX not "make sense?" Do public/protected/private modifiers in Java not "make sense?"

Stop confusing a match to your personal comfort zone for actual quality or fitness-for-purpose.

Re: Python’s Weak Performance Matters

#326

Post by PyComfy »

tom_mellior wrote: post #180
PyComfy wrote: post #104

Earlier quoted context omitted.

Naive interpretation of the bytecode (not even pre-decoded, just a switch statement). And almost everything is resolved in the dynamic environment. for example, a = foo.bar(b) is actually ldict = locals() ldict['a'] = ldict['foo'].__getattribute__('bar')(ldict['b'])

This is a bit misleading. You suggest that local variables are looked up by name in a dictionary, which is not the case. They are looked up by indexing into a C array, with the index being a constant in the bytecode. That's quite a lot simpler. Here is the corresponding code (look above for the definition of the GETLOCAL macro): https://github.com/python/cpython/blob/fc1ce810f1da593648b4d... So your code should be mo…

ah sorry. i did

    import dis
    dis.dis("a = foo.bar(b)")
which gave

    1           0 LOAD_NAME                0 (foo)
                2 LOAD_ATTR                1 (bar)
                4 LOAD_NAME                2 (b)
                6 CALL_FUNCTION            1
                8 STORE_NAME               3 (a)
               10 LOAD_CONST               0 (None)
               12 RETURN_VALUE

Re: Python’s Weak Performance Matters

#327

Post by tom_mellior »

PyComfy wrote: post #326
tom_mellior wrote: post #180

Earlier quoted context omitted.

This is a bit misleading. You suggest that local variables are looked up by name in a dictionary, which is not the case. They are looked up by indexing into a C array, with the index being a constant in the bytecode. That's quite a lot simpler. Here is the corresponding code (look above for the definition of the GETLOCAL macro): https://github.com/python/cpython/blob/fc1ce810f1da593648b4d... So your code should be mo…

ah sorry. i did import dis dis.dis("a = foo.bar(b)") which gave 1 0 LOAD_NAME 0 (foo) 2 LOAD_ATTR 1 (bar) 4 LOAD_NAME 2 (b) 6 CALL_FUNCTION 1 8 STORE_NAME 3 (a) 10 LOAD_CONST 0 (None) 12 RETURN_VALUE

Ah, OK. Yes, those LOAD_NAMEs are slower than LOAD_FAST. If you put the code into a function, you get this:

    >>> def f(foo, b):
    ...     a = foo.bar(b)
    ... 
    >>> dis.dis(f)
      2           0 LOAD_FAST                0 (foo)
                  3 LOAD_ATTR                0 (bar)
                  6 LOAD_FAST                1 (b)
                  9 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
                 12 STORE_FAST               2 (a)
                 15 LOAD_CONST               0 (None)
                 18 RETURN_VALUE
LOAD_FAST is the normal case for locals inside a function. Not sure off the top of my head where LOAD_NAME would be generated in normal usage (i.e. where you don't evaluate code from a string).

Edit: Also, I'm talking about Python 3. Maybe you aren't.

Re: Python’s Weak Performance Matters

#328

Post by rhaps0dy »

newen wrote: post #323
rhaps0dy wrote: post #316

Earlier quoted context omitted.

>If you're doing something which is actually new, like PhD methods research, you need to be writing a lot of stuff from scratch. Sometimes you also reuse a lot of stuff, it depends. For machine learning in particular, almost everything uses some sort of gradient-based optimisation algorithm. In these cases, it is very useful to have an automatic differentiation library. My coworker said Julia has about 3, IIRC, and u…

> until an amalgamation of them is merged into the standard library Julia isn't completely ready That doesn't quite make sense. I'm sure there are a few more autodiff libraries in Julia than 3. You would just use the one that fits your use case. PS. Ohh re-reading your comment, you want an autodiff library in Julia's standard library. That is very unlikely to happen since it's not (very) hard to cook up an autodiff l…

Yeah, you read it correctly the second time :)

>That is very unlikely to happen

Well, my co-worker says people are working on it. I asked him whether I should try to adopt Julia and "not until autodiff is in the standard library" was his response.

>autodiff is not widely used

If you look only at the machine learning community, that is false. Autodiff is used all the time, to optimise loss functions using a variant of gradient descent. For neural nets, gaussian processes, SVMs... Not decision trees/forests, but these are not more popular than all the others combined.

Re: Python’s Weak Performance Matters

#329

Post by gspetr »

bbatha wrote: post #272
halbritt wrote: post #265

Earlier quoted context omitted.

To your point 1: This is the reason that AsyncIO exists in Python 3.6 and IIRC Facebook is pushing really, really hard to adopt it.

Absolutely, but its arguably 10 years too late. Node has already eaten python's lunch in the server space. To get your existing python code working on async you may basically need a full rewrite including any libraries that you pulled in. At that point most companies ask themselves if python is really the right language to conduct a rewrite in.

https://en.wikipedia.org/wiki/Twisted_(software)

7 years ahead of node.js

Re: Python’s Weak Performance Matters

#330

Post by one-more-minute »

rhaps0dy wrote: post #328
newen wrote: post #323

Earlier quoted context omitted.

> until an amalgamation of them is merged into the standard library Julia isn't completely ready That doesn't quite make sense. I'm sure there are a few more autodiff libraries in Julia than 3. You would just use the one that fits your use case. PS. Ohh re-reading your comment, you want an autodiff library in Julia's standard library. That is very unlikely to happen since it's not (very) hard to cook up an autodiff l…

Yeah, you read it correctly the second time :) >That is very unlikely to happen Well, my co-worker says people are working on it. I asked him whether I should try to adopt Julia and "not until autodiff is in the standard library" was his response. >autodiff is not widely used If you look only at the machine learning community, that is false. Autodiff is used all the time, to optimise loss functions using a variant of…

Maybe there was some small miscommunication here – we are indeed working on "one AD to rule them all" (Capstan, [1]), but it won't go in the standard library as such (there's no need as it will be just as good as a package).

That said, Capstan relies on very new compiler technology and still requires some deep changes there, so will only work on future Julia versions (which may be what he was referring to).

Until then, Flux [2] has an AD that's well-suited to ML and works on current Julia versions.

[1] https://github.com/JuliaDiff/Capstan.jl/ [2] https://fluxml.github.io/

Post reply on HN