kmod

Good question, we talked about it a tiny bit in our previous blog post and are planning on doing more in-depth blog posts in the future. I added a very brief summary to the github readme:

- A very-low-overhead JIT using DynASM

- Quickening

- Aggressive attribute caching

- General CPython optimizations

- Build process improvements

We use completely separate benchmarks, where our Pyston benchmarks are quite a bit "harder" and PyPy is only 12% faster on them while using 4x the memory.

I'm still learning about Cinder, but my initial impression is that there are many similar techniques used, and maybe one interesting difference is that with Pyston we've focused more on out-of-the-box performance while Cinder has had an opportunity to co-optimize the runtime with a particular codebase and presumably gets better results if you're able to do that.

My 2 cents as an implementer of an alternate Python implementation -- I am skeptical about this approach. We tried the "provide a limited API" approach in the past and found the following things:

- People actually use the "hard to implement" parts of the C API

- Moving things from macros to function calls can often be quite detrimental to performance

- C extensions have been co-optimized with the C API, so changing the C API will make things less optimized

- These "check if runtime debugging is enabled" checks are not free

My guess is that this will end up in a tough middle ground where extension writers will be faced with a tradeoff along the lines of making their extension 10% slower for 99% of their users in order to make things 2x faster for 1% of their users.

Right now there are only two sellers

My review included the picture of the card, they just didn't reattach it to my rejection email

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.

This is just a comment on my personal use of Python for competitive programming: I've never used numpy for competitive programming or thought that it would be a good tool for that. PyPy seems like a great solution for the highly-numerical algorithms that these contests tend to lead to.

So I would not call this "scientific computing". Personally I consider competitive programming to be it's own use case.

And as much as we want to improve scientific computing in Python, it's very hard since the work is done in C. Our current hope is to help mixed workloads, such as doing a decent amount of data-preprocessing in Python before handing off to C code.

We started with an LLVM-based JIT in Pyston v1. Our experience with the two jits is that it's very nice that DynASM is ~2 orders of magnitude faster, and also that we have not been able to extract enough high-level knowledge to make a powerful JIT like LLVM worth it. We do use LLVM elsewhere in our build process, and we hope to write some future blogposts about all of this.

All my CodeJam solutions are in Python :)

While we could certainly go in this direction, we're not planning to, because in our experience optimizations for different workloads are largely distinct, and this use case is already handled well by PyPy.

I would say there's a small minority of our changes that we can upstream, and eventually we'd like to upstream them. For the rest, I would say the different set of priorities for the two projects means they probably will stay separate:

- In the blog post I linked to an issue of someone trying to upstream a quickening implementation and meeting resistance due to the added complexity

- CPython prefers portability over performance, and we added a number of big build dependencies that may not work on all the platforms that CPython supports, though from our perspective it works on all the important ones

- CPython has included a number of performance-degrading features over the years and we plan to start cutting out some that are only used for debugging but still hurt release mode. I don't know for sure but I would expect resistance to backing out those changes.

There are more, but the general idea is that the two projects will make different tradeoffs. Maybe there is a world where the code all lives in the same repository but is gated between different behaviors, but the CPython maintainers have already rejected a proposal like that.

Whoops, I forgot we had that up, I took it down until we can post an up-to-date image

From my experience in this area:

- There are companies which would be willing to pay large amounts of money (more than he's asking for) for the speedups he's promising

- There are other similar efforts underway (such as ours) which have implemented some of his ideas and the gains are much smaller than he anticipates (for real code, microbenchmarks are another story)

I'll add my experience as a counterpoint -- I've been running my own wordpress blog for several years now, and the amount of effort involved has been surprisingly high. I've had to tune apache numerous times (seriously, who wants to tune apache in order to write a blog), I have to regularly defend it against malicious traffic, and I've had to manually fix the installation after a plugin installation prevented wordpress from starting. Plus since it's a one-off, I'm not convinced that I could bring it back if anything were to happen to the server it runs on.

For a project blog I used hosted wordpress, and I found that to be a pretty good middle ground. Honestly I can't think of a case where running your own wordpress server is a good use of your time.

This is a common view but I've never heard it from someone who has tried to optimize Python. Personally I think that Python is as much more dynamic than JavaScript as JavaScript is than C. (I can't talk for the other languages.)

Just look at the small example in this post: - converting things to strings invokes several layers of dynamic dispatches - Python has an extremely expressive calling convention that can cause a lot of overhead

Another example that I like to give is that in Python you can inspect the stack variables of exited frames! The Python-on-mature-VM projects have also not resulted in great performance.

I hear your argument a lot, and I disagree and I also believe it misguides optimization efforts ("let's just apply JS techniques to Python") including our early ones with Pyston. It's part of what I'm trying to get at with this blog post, but maybe I'll write another one specifically about Python vs other languages.

I don't know how to interpret the results of --trace-opt, but when I increase the iteration bounds 10x the running time increases 10x, so I don't think the code is being eliminated. This is with node v12.13.0

It used to be this way, but at some point they added a faster calling convention and moved a number of things to it. Calling type objects still falls back to the old convention though.

There's a minor but important point: the amount of work str() has to do depends on its input type. In particular, if arg.__str__() returns a string or a subtype of string or not a string, str() will call different tp_init functions. So we can't get rid of the args tuple until after the optimization of knowing that arg.__str__() returns an string (which is why I did them in that order). So I guess the condition is a little bit weaker than str(int) but it's more than str() of one arg.

Yep! It's slightly worse than you would think. Here's a (slightly edited) version of how the argument passing works

  static PyObject *
  unicode_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
  {
      PyObject *x = NULL;
      static char *kwlist[] = {"object", "encoding", "errors", 0};
      char *encoding = NULL;
      char *errors = NULL;
  
      PyArg_ParseTupleAndKeywords(args, kwds, "|Oss:str",
                                  kwlist, &x, &encoding, &errors))
  }

Notice the call to PyArg_ParseTupleAndKeywords -- it takes an arguments tuple and a format string and executes a mini interpreter to parse the arguments from the tuple. It has to be ready to receive arguments as any combination of keywords and positional, but for a given callsite the matching will generally be static.

I have to disagree that those are "interpreter" overheads, since the later versions of the benchmark do not use the Python interpreter at all yet still suffer from these overheads. Maybe disagreeing on the wording is pedantic though, since I think the real discussion is what can be done about it.

We definitely agree directionally: you can create specific implementations of operations that are fast for their inputs. But look at how specific we have to get here. It's not just on the type of the callable: we have to know the exact callable we are calling (the str type). And its behavior is heavily dependent on its argument type. So we need a code path that is specifically for calling the str() function on ints. I would argue that this is prohibitively specialized for an interpreter, but one can imagine a JIT that is able to produce this kind of specialization, and that's exactly what this blog post is trying to motivate.

That's a good question, I updated the post with a quick blurb on this. There may be a number of potential ways to distinguish them, so I gave the one that I was using for the blog post.

This is what I get for hosting my own wordpress server. It was struggling and I installed a caching plugin which took down the site. Should be back up, sorry!

I don't know PHP, but feel free to send a pull request!

It's interesting to note that the Bitcoin ecosystem depends on BGP being secure

I agree that AWS has economies of scale that makes it hard to build a better/cheaper S3, but one way you can get around this problem is by building to lesser requirements. S3 has to work for all use cases, but if you know you need less of something costly (say, less IOPs) you can build a system that's cheaper than S3 even if the individual components are more expensive than S3 is paying.

Sure, let's dig into networking. Who pays for rereplication traffic? If you do 64-of-96 RS encoding, that means for every failure you need to transfer 64x the lost storage capacity. If you're targeting a "low individual uptime but high aggregate uptime" model this means you need to be storing data in multiple sites -- and dedicated cross-geo bandwidth is expensive. I agree that in the happy case you can use low-bandwidth cheap equipment, but to get good reliability you need to provision for larger clustered failures such as rack- and row-level outages.

I worked on the design of Dropbox's exabyte-scale storage system, and from that experience I can say that these numbers are all extremely optimistic, even with their "you can do it cheaper if you only target 95% uptime" caveat. Networking is much more expensive, labor is much more expensive, space is much more expensive, depreciation is faster than they say, etc etc. I don't think the authors have ever done any actual hardware provisioning before.

I didn't read all their math but I expect their final result to be off by a factor of 2-5x. Hard drives are a surprisingly low percentage of the cost of a storage system.

HN has a 80-character title limit and it's not always clear how to paraphrase a longer title.

They're really in a different league. My favorite example is the ad-hoc stack analysis that Python lets you do -- and not just of the current stack, but of already-exited stack frames! This is free in CPython but prevents sizable performance gains from JITs (I don't remember the exact numbers, but I think it was multiple percent).

51% attacks on most currencies are quite easy if you attack the mining pools. http://blog.kevmod.com/2019/01/pooljacking-easy-51-attacks-a...