kmod

I don't think it's the cable length: 0.5ms is 150km in fiber or about 100km in copper. Cable length is important in HFT where you are measuring fractions of micro seconds.

It's really quite amazing to me that HFT reduces RPC latency by about three orders of magnitude, I feel like there are lessons from there that are not being transferred to the tech world.

Fyi "this language has been under design for a long time" is not always perceived as a good thing since it can be associated with navel gazing. IMO I'd advertise the language based on the core benefit you think it provides

I'd say this is because the term "AI" has been redefined, not because the same work is being done in a different way

The issue I have with these arguments is that they assume that just because a certain thing has flaws there must be a better solution. What if predicting long-term effectiveness using a limited amount of time is inherently approximate at best?

I'm sure interviewing can be improved, but I think it's worth remembering that we are one of the few industries that actually tries to do skills-based interviewing. When people say "get rid of leetcode" or what not, are they really saying that the alternative that the rest of the world uses (resume screen plus vibes check) is preferable?

As someone else mentioned, test suites are a bit of a tough case for JITs. That said, we really don't want to slow down any workloads, and I suspect that something might be going wrong if you are getting a measurable slowdown.

Is this project public? I'd love to investigate

I'm not sure of the bindingness of this page [1], but the FTC says that transactional-vs-promotional is determined by what what a recipient "reasonably interpret[s]" it as, not what the sender says it is. Not that this prevents the kind of abuse that you mention, but I find if I send a email responding to the kind of email you mention and I politely explain how it is a violation of CAN-SPAM and if reported is a five-figure fine per email, then I magically get added to some sort of "do not send promotional emails that we call transactional" opt-out.

[1] https://www.ftc.gov/business-guidance/resources/can-spam-act...

Ah this is a different version of the problem. There are quite a few listed on the wikipedia page.

I believe the version you are talking about is just a simple equivocation.

Every envelope you open will have a higher expected value than the previous one. This is not paradoxical, it is a standard property of probability distributions with infinite means.

I believe the problem you are trying to elicit is that you can almost show that either envelope is a priori better than the other. The problem with this is that the means are infinite so the math isn't sound. So there's not an actual contradiction; the strategy is to open either envelope and then switch to the other one. It's unintuitive but only because we're not used to reasoning about distributions with infinite means.

If I open an envelope with $10 then I know that there is $20 in the other envelope.

As soon as you assign a well-formed probability distribution to the money in the envelopes you will find that opening the first envelope is informative.

If you disallow negative values of k then you break the symmetry argument, and you do indeed get quite a bit of information by opening an envelope.

I assume you meant to use a exponential base <0.5 so that the mean is finite

Note that the problem requires allowing arbitrarily small amounts of money in the envelopes, otherwise you would know at some point that you have the smallest amount of money possible. So in your formulation, you have to let k be negative as well.

If it is truly the case that the second envelope has equal probability of having half or double the amount of money as the first, then you can prove that the probability distribution of money in each envelope is not well-formed (has total mass either zero or infinity). This means the premise is already contradictory, and further false conclusions (such as "P and not-P" for P="it is better to switch") are not surprising.

Bit of context for this:

- Cheaper Python frames are enabled by making some semantic changes to the language, mostly by removing some dynamic functionality that no one uses

- "Inlined Python function calls" is a bit misleading: Python functions are not inlined, it's the "code that does the bookkeeping for calling a Python function" that is now eliminated for Python-to-Python calls.

- The most important part of the specializing interpreter is the attribute caching, which is quite significant

Source: I work on Pyston, where we do many similar things (but can't make semantic changes to the language)

GraalPython only supports a relatively-small subset of the Python language, making it impossible to collect numbers on realistic benchmarks

I think the interviewing process is an extremely informative view into what it's like to work at that company. The exact steps to take depend on how bad it is / how much you want the job / other context, but I think it's a safe assumption that they are treating you like they treat their coworkers, and that this is not unusual behavior for the company.

I've ended a few interview processes at companies due to things I observed during onsite interviews (not necessarily rudeness), and with the benefit of hindsight I think those were absolutely the right call.

I did have one particularly rude interviewer once, but since it was in finance I thought it was a "stress interview". I took the job, and it turns out that this person was just toxic and the company had a culture of tolerating toxic people if they were high enough performers. I'm still glad I took the job, but the experience definitely was strong evidence of the link between what you see in an interview and what you get if you work there.

Cinder does this (invalidation), and both Faster CPython and Pyston use guarding.

I tried to benchmark GraalPython for the talk but the compatibility situation was so poor that I wasn't even close to being able to run any benchmarks.

Python dictionaries now have version counters that track how many times they were modified, so the quick check is to ask "was len not overidden last time and is the number of modifications to the globals the same as it was last time".

Personally I think it's valid to consider selection-bias effects in authorship -- in general, things are written by the people who are the most excited about the topic, which leads to there being a bias towards excitement. I don't think it invalidates the research but it feels like a valid point.

I think an interesting observation is that this anti-psychedelics post is written by someone who doesn't even want to try them, so this argument of his also says to treat this blog post with skepticism.

I worked on this for my masters thesis! The thesis was for a specific part but the group worked on the problem as a whole, see https://dspace.mit.edu/handle/1721.1/49844

IMO there are two things that make the current abstraction of a computer as a unit make sense:

- You (mostly) don't have to try to handle partial failures within a computer. Partial failures are what make distributed systems hard.

- The difference in communication costs between two cores in a single machine is several orders of magnitude lower than communicating with a separate machine using commodity technologies. So while yes, "it's all just distributed" and you can use a common abstraction, a large enough constant factor difference means that you still will have to look through the abstraction to build a performant system.

There has been some effort to quantify "AI scaling laws": ie how much performance increases as we scale up the resources involved. See section 1.2 of https://arxiv.org/pdf/2001.08361.pdf

My main takeaway from that paper is that a 2x increase in training cost improves performance by 5% (100x by 42%). I only skimmed the paper though.

To me this says that model scaling will not get us very much farther: we can probably do one more 100x but not two.

I talked to someone working on model scaling and they see the same numbers and draw a very different conclusion: my interpretation of their argument is that they view scaling money as easy versus finding new fundamental technical advances.

This kind of thing scares me about the current state of AI. Language models are trained to produce text that looks like the training data, but if the training data has falsehoods they will happily repeat those falsehoods.

I just put the example into GPT3: Prompt: Can an email address contain more than one @ sign? Answer: No, an email address can only contain one @ sign.

I'm on my phone so it's a bit laborious to test more

I think these sorts of arguments are not great because they confuse "limiting behavior" with "behavior at the limit". Yes if you are able to construct an infinite-sized MLP it can exactly replicate a given function, and you can construct a sequence of MLPs that in some sense converge to this infinite behavior. But in other measures the approximation might be infinitely bad and never get better unless the net is truly infinite.

For an example, consider approximating the identity function [f(x) = x] with a sigmoid-activation MLP. For any finite size of the net, the output will have a minimum and maximum value. One can change the parameters of the net to increase the range of the output, but at no point is the output range infinite. So even though you can construct a sequence of MLPs that in the limit in some sense converges to the identity function, in some sense it never does.

The same kind of thinking that leads to the conclusion "neural nets are universal approximators" would support the existence of perpetual motion machines; check out the "ellipsoid paradox" for more info.

Shameless plug: Python 3.11 comes out this October and is slated to be 10-20% faster, but Pyston is already available and is 30% faster. We do the things that are listed in this pdf, but also additional things that will probably never make it into mainline Python (such as adding a JIT)

https://github.com/pyston/pyston

Yes, definitely. Python is much much more dynamic than Javascript -- the jump in dynamicness of Javascript to Python is about equivalent to Java to Javascript, and similarly requires a different set of techniques.

The single example I typically give is that in Python you can inspect stack frames after they've exited! This has concrete implications on your VM design.

Another example is that the multiple dispatch protocol for binary operations (such as addition) is sufficiently complicated that you generally cannot encode it into your compiler. We have been able to have a simplified version of that by building a tracing JIT for C, which is able to understand the dispatch protocol, but it is not always applicable.

Source: I've been working on Python optimization for several years as part of the Pyston project.

First, I strongly recommend using a tiling window manager. There aren't many logistical things you can do to improve your programming output but this is one.

I used XMonad for many years and finally had to give up and switch to i3, so I would recommend using that

The first problem was that they broke my configuration file with every release. I'm not a Haskell expert so fixing it was very time consuming

The second is that their gnome integration is quite bad. Also it's different for every combination of XMonad version and Ubuntu version and eventually I hit a combination that I couldn't get to work

So it was great when it worked but it didn't always work, and I'm now a happy i3 user

I've been a user of Flow Club for a while now and I highly recommend it even though that's probably not in my personal interest. I often find that I am >2x as productive during these hours, which I find remarkable, and sometimes it gets me to crank out something I would have otherwise procrastinated. I find it great as well for adding structure to my unstructured work schedule (I work for myself). The combination of forced intention setting with light external accountability is really powerful.

We run the numpy testsuite as part of our testsuite so to our knowledge it works well.

Imports are faster! Maybe not as much as you're hoping but we did optimize them a bit.