undefined | Better HN

0 pointsspiffytech5y ago0 comments

That kind of tit-for-tat in benchmarks seems like it's counter to the goal of benchmarks: what kind of performance could I expect to see using technology $FOO? Crucially, that question depends on how someone will realistically implement $FOO.

I like PyPy as an example: on the surface, implementing a Python runtime in Python and expecting performance gains seems crazy. PyPy manages to outperform CPython because although a C implementation should theoretically be faster, realistically the increased expressiveness of Python lets the PyPy devs opt into optimizations the CPython devs find out of reach.

I don't know C or Rust well enough to comment on these specific scenarios, but if two technologies can be fast, and one makes that speed accessible while the other encourages implementors to leave performance on the table, that's much more useful information to me than seeing a back-and-forth where folks compete to implement optimizations I'll never make in my own projects.

0 comments

moonchild5y ago

> PyPy manages to outperform CPython because although a C implementation should theoretically be faster, realistically the increased expressiveness of Python lets the PyPy devs opt into optimizations the CPython devs find out of reach.

Pypy outperforms cpython for the simple reason that pypy is a jit where cpython is a basic bytecode interpreter. Anything else is icing on the cake.

The only reason python seems slow as an implementation language is because it was traditionally slow; the reason it was traditionally slow is that cpython, the only major implementation, is slow. Common lisp, for instance, is similarly dynamic (moreso, in fact), also is also generally natively compiled by itself, and is quite performant.

aidenn05y ago

Common Lisp (hereafter Lisp for concision) is differently dynamic, not strictly more dynamic.

One quick example: standard-class objects in Lisp are mostly more dynamic than python objects[1] but structure-class objects are quite static, and compilers will use this to their advantage.

On top of this, functions in python are in fact objects; in python you can do this just fine:

  def foo():
    foo.bar = 3

  def bar():
    print(foo.bar)

There are obviously other ways to accomplish this in lisp, but the fact that someone might do something like this can inhibit optimizations.

If you read the Lisp specification you will see dozens of places where they allow for opting out of dynamism in ways that help the compiler optimize. Type declarations are one and the fact that a function defined in a single file is considered to have a fixed definition for the scope of the file is another.

1: It's not quite as easy to add new slots to Lisp standard-class instances on the fly as it is to python class instances, but it's doable, and Lisp, of course, supports class redefinition in a way that few other languages (including Python) do.

spiffytechOP5y ago

PyPy has a JIT because using Python as the implementation language made it simple to build a runtime generator instead of a single runtime implementation, so RPython (the underlying PyPy tech) can generate a JIT and non-JIT runtime from the same source code. Conversely, the CPython team doesn't have the resources to make a JIT runtime the bespoke way that's more typical for these projects.

https://morepypy.blogspot.com/2011/04/tutorial-part-2-adding...

naniwaduni5y ago

CPython isn't a JIT because its goals as a portable reference implementation would be much harder to achieve with a JIT.

To put it another way, there's a reason PyPy trails CPython language features on the scale of literal years. This is not explained by the affordances of the language they're written in! They're just projects with very different requirements which, on some platforms, happen to run a lot of similar-looking code.

1 more reply

vitus5y ago

You raise a good point. I've always been fascinating by PyPy's performance, personally -- anecdotally, I've achieved ~10x speedups from just running a script with `pypy` instead of `python`. I always attributed that to better performance of the JIT, but I could be wrong.

I have nothing against Rust personally, but it's ultimately not an apples-to-apples comparison if they're not implementing the same algorithm, or even if they're not using the same mechanisms (e.g. Rust explicitly using SSE intrinsics, which are certainly available to C in just as idiomatic a fashion).

gameswithgo5y ago

comparing apples to apples is pointless, they are both apples.

and you can always compare “equivalent” algorithms as some languages may not be able to efficiently express the same algorithm as another. i know what you are after, but trying to have some benchmark that is “fair” according to some spec that is important to your needs will just be seen as pointless to others. benchmark game at least lets us see what the performance ceiling is of various languages, and anytime you object to a language having a worse implementation you may go fix it.

i think what anyone with a clue understands is that C C++ and Rust all have roughly equivalent performance ceilings. Nobody really thinks Rust is faster than C now.

vitus5y ago

> Nobody really thinks Rust is faster than C now.

The submission title would beg to differ.

(I know, it explicitly calls out "benchmarks" as the context.)

I think languages like Rust or Swift have significant advantages around safety over C/C++, while not sacrificing much in terms of performance. But if one language's benchmark contributors are willing to put in more effort than another's to eke out additional performance, then you're going to see skewed results in favor of whichever has the more fervent evangelists or whichever language has more to prove.

If the goal is to compare performance of two languages which can express the same optimization in exactly the same way, and only one uses it, then the benchmarks fail in that respect.

1 more reply

sli5y ago

I admit I'm destroying the metaphor here but there are a lot of useful comparisons to be made between different cultivars of apple and those comparisons have implications on their applications.

1 more reply

mkl5y ago

> That kind of tit-for-tat in benchmarks seems like it's counter to the goal of benchmarks

Yep. There are good reasons why this set of benchmarks is called The Computer Language Benchmarks Game.

igouy5y ago

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

FartyMcFarter5y ago

> I like PyPy as an example: on the surface, implementing a Python runtime in Python and expecting performance gains seems crazy.

Not if it includes a JIT compiler, as PyPy does. I don't know much about PyPy, but if most of the time is spent in JITted machine code, the fact that it's written in Python may not affect performance much.

pjmlp5y ago

Kind of, PyPy is a metacircular JIT compiler, it uses RPython a Python subset.

cygx5y ago

realistically the increased expressiveness of Python lets the PyPy devs opt into optimizations the CPython devs find out of reach

Not really: It's the compilation strategy (that whole meta-tracing JIT compiler thing, compared to a simple bytecode interpreter) that makes the difference, not the surface syntax of the implementation language - which is actually not 'real' Python, but a restricted, less dynamic subset known as RPython.

Also note that the CPython is deliberately kept 'dumb'.

j / k navigate · click thread line to collapse

0 comments

moonchild5y ago

Pypy outperforms cpython for the simple reason that pypy is a jit where cpython is a basic bytecode interpreter. Anything else is icing on the cake.

aidenn05y ago

Common Lisp (hereafter Lisp for concision) is differently dynamic, not strictly more dynamic.

One quick example: standard-class objects in Lisp are mostly more dynamic than python objects[1] but structure-class objects are quite static, and compilers will use this to their advantage.

On top of this, functions in python are in fact objects; in python you can do this just fine:

  def foo():
    foo.bar = 3

  def bar():
    print(foo.bar)

There are obviously other ways to accomplish this in lisp, but the fact that someone might do something like this can inhibit optimizations.

spiffytechOP5y ago

https://morepypy.blogspot.com/2011/04/tutorial-part-2-adding...

naniwaduni5y ago

CPython isn't a JIT because its goals as a portable reference implementation would be much harder to achieve with a JIT.

1 more reply

vitus5y ago

gameswithgo5y ago

comparing apples to apples is pointless, they are both apples.

i think what anyone with a clue understands is that C C++ and Rust all have roughly equivalent performance ceilings. Nobody really thinks Rust is faster than C now.

vitus5y ago

> Nobody really thinks Rust is faster than C now.

The submission title would beg to differ.

(I know, it explicitly calls out "benchmarks" as the context.)

If the goal is to compare performance of two languages which can express the same optimization in exactly the same way, and only one uses it, then the benchmarks fail in that respect.

1 more reply

sli5y ago

I admit I'm destroying the metaphor here but there are a lot of useful comparisons to be made between different cultivars of apple and those comparisons have implications on their applications.

1 more reply

mkl5y ago

> That kind of tit-for-tat in benchmarks seems like it's counter to the goal of benchmarks

Yep. There are good reasons why this set of benchmarks is called The Computer Language Benchmarks Game.

igouy5y ago

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

FartyMcFarter5y ago

> I like PyPy as an example: on the surface, implementing a Python runtime in Python and expecting performance gains seems crazy.

pjmlp5y ago

Kind of, PyPy is a metacircular JIT compiler, it uses RPython a Python subset.

cygx5y ago

realistically the increased expressiveness of Python lets the PyPy devs opt into optimizations the CPython devs find out of reach

Also note that the CPython is deliberately kept 'dumb'.

j / k navigate · click thread line to collapse