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

141–150 of 211 posts

Re: Pyston v2: Faster Python

#141

Post by FartyMcFarter »

toolslive wrote: post #36
rrdharan wrote: post #17

Earlier quoted context omitted.

Python is a welcoming community, but they are decidedly not welcoming of contributions that significantly increase the complexity of the CPython reference implementation. This has been discussed extensively: https://news.ycombinator.com/item?id=11125769

it's _still_ essentially the same switch(opcode) based interpreter it was 20 years ago. no threading, no super instructions, no jitting, nothing. https://github.com/python/cpython/blob/master/Python/ceval.c...

> no threading,

CPython does use threads (on Linux, it spawns one pthread per Python thread). However it also has a lock (the infamous GIL) that prevents those threads from interpreting Python code simultaneously.

Re: Pyston v2: Faster Python

#142

Post by kmod »

EdSchouten wrote: post #9

Not that it's necessarily a bad thing, but it looks like the Pyston project isn't getting a lot of updates: https://github.com/pyston/pyston/commits/v2.0

I updated the repo in the middle of this comment thread; it used to show the v1 code, but since that was confusing people now it's just a stub that redirects you to the blog.

Re: Pyston v2: Faster Python

#143

Post by solidasparagus »

throwaway894345 wrote: post #58
mrtranscendence wrote: post #49

Earlier quoted context omitted.

> Meanwhile, there are many other languages which are not only performant, but which are rapidly encroaching on Python's historically unique(ish) "easiness" What are those languages? I may have a blindspot, but the languages that get enough buzz for me to notice are either not competing with Python in important dimensions (e.g. Rust) or have a narrower focus (e.g. Julia). Elixir maybe? JavaScript and its derivatives?…

> I'd love to find a viable competitor to Python that's strictly better than it. I strongly recommend Go as a better Python. Personally, I think it's easier to write than Python (although people who care very little about correctness will be bothered a bit by the type checker), and the tooling is many times better (single-binary deployments, great dependency management, etc are awesome). Also, the performance is abou…

Go and Python have pretty minimal overlap IMO. If you are using Python for anything other than a server or CLI, Golang is not a very good replacement for Python.

Some of Python's strengths that I work with regularly are dynamism, easy data exploration, visualizations, succinct & customizable syntax, extremely strong data science libraries, REPL/Jupyter, C bindings, easy to use packaging solution via PyPi (bet some people are going to disagree with that one), quick to prototype code. If you really need performance in Python, you can probably get it out of the box (if you can run deep learning with Python, performance isn't a limitation).

I love Go and use it for a bunch of projects, but I've only once wanted to move a project from Python to Go and that was a performance-centric CLI that was only written in Python originally because of how quickly it let us prototype in comparison to Go.

Re: Pyston v2: Faster Python

#144

Post by solidasparagus »

throwaway894345 wrote: post #51
sk2020 wrote: post #44

Earlier quoted context omitted.

Scipy has a poor performance ceiling? Numpy has a poor API? Compared to what? Eigen? Whatever the Scala guys use? That sounds kind of silly to me, especially when hardly anyone is actually CPU-bound, anyway.

WRT performance ceiling, I'm mostly talking about things like Pandas which eagerly evaluate and which aren't amenable to a parallel execution model (multiple threads operating on the same data frame with minimal contention). WRT poor APIs, I'm talking about things like matplotlib or pandas or etc that take a whole slew of arguments and try to guess the caller's intent by inspecting the types of the arguments. The ref…

IMO panda's lenient inputs is a godsend when you are working with real-world, dirty data regularly. It's my favorite API I've ever worked with because it lets me focus on my high-level tasks and it takes care of the things I don't really care about like whether I am working with a list of dicts or a dict of lists or whatever.

But once you've done the cleaning/exploration, you should move any heavy computing to a high-performance library like numpy.

Re: Pyston v2: Faster Python

#145

Post by 0thgen »

xapata wrote: post #67
throwaway894345 wrote: post #51

Earlier quoted context omitted.

WRT performance ceiling, I'm mostly talking about things like Pandas which eagerly evaluate and which aren't amenable to a parallel execution model (multiple threads operating on the same data frame with minimal contention). WRT poor APIs, I'm talking about things like matplotlib or pandas or etc that take a whole slew of arguments and try to guess the caller's intent by inspecting the types of the arguments. The ref…

matplotlib and pandas were designed with the idea of mimicking interfaces more popular than the project (when they were first conceived). The "easy" interface is a large part of why those projects are now more popular then their inspirations.

very true; I found matplotlib very appealing because I didn't have to relearn anything coming from matlab

Re: Pyston v2: Faster Python

#146

Post by 0thgen »

newen wrote: post #76
sk2020 wrote: post #44

Earlier quoted context omitted.

Scipy has a poor performance ceiling? Numpy has a poor API? Compared to what? Eigen? Whatever the Scala guys use? That sounds kind of silly to me, especially when hardly anyone is actually CPU-bound, anyway.

Numpy has a very poor API compared to Julia, Matlab, Mathematica, R. That’s just me comparing to the ones I know. It’s a mishmash of methods and functions, in-place operations and non-modifying operations, confusing indexing and broadcasting API. There are much better things available for array manipulation.

I'm curious what the outcome would be if we ran a poll asking what people find easier. I find numpy's API more intuitive, but I could be a minority.

I will say that the differences between python and R syntax are almost trivial; I've taught classes with python and R example scripts that are almost _exactly_ the same, and run in both languages

Re: Pyston v2: Faster Python

#147

Post by radlad »

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…

Link?

Re: Pyston v2: Faster Python

#148

Post by pansa2 »

bywaterstreet wrote: post #122
vosper wrote: post #60

Earlier quoted context omitted.

What's Go like for REPL-driven / exploratory development? That's mostly how I use Python.

Go has nothing on Python in this regard. I write Go every day, and come from a Python background. I often describe Go as the strongly-typed, more performant version of Python. I say this mostly because my Go code isn't too dissimilar from my Python code (structure, naming, packages). But I still drop into Python if I want to do something quickly. I don't really know why. Maybe it's the Go tooling, e.g. unused variabl…

> I often describe Go as the strongly-typed, more performant version of Python.

I've heard Go described this way several times, but I've found it to be a significantly lower-level language than Python.

For example, it's much more verbose. In this recent blog post [0], the author converts some C++ code to Go - and it gets longer. 57 lines of C++ become 65 lines of Go. The same code in Python is about 20 lines.

In particular, the author's Go code requires five lines to do the equivalent of Python's `with open(path) as f` and four lines for the equivalent of `word_array = list(word_counts.items())`:

    f, err := os.Open(path)
    if err != nil {
        return err
    }
    defer f.Close()

    // [...]

    wordArray := make([]WordCount, 0, len(wordCounts))
    for word, count := range wordCounts {
        wordArray = append(wordArray, WordCount{word: word, count: count})
    }
[0] http://jmoiron.net/blog/cpp-deserves-its-bad-reputation/

Re: Pyston v2: Faster Python

#150

Post by smabie »

sk2020 wrote: post #44
throwaway894345 wrote: post #29

Earlier quoted context omitted.

This is why I see little hope for Python, which is to say that while I'm sure it will continue to have a large following for many years a la C, C++, etc, I don't have hope for it being an exciting language or one that is particularly productive. Python already has performance and packaging problems which don't seem to be easily divorced from CPython, since virtually the whole reference implementation is depended upon…

Scipy has a poor performance ceiling? Numpy has a poor API? Compared to what? Eigen? Whatever the Scala guys use? That sounds kind of silly to me, especially when hardly anyone is actually CPU-bound, anyway.

My work is 100% CPU bound, and I am very angry at Python for wasting so much of my time.
Post reply on HN