From 4984122f7ce358932b4d0804cd33e72c248433c0 Mon Sep 17 00:00:00 2001 From: Rafia Minhaj Date: Thu, 15 Oct 2026 00:30:34 +0530 Subject: [PATCH] Fix typos in multiple blog posts - jit-on-track: misinterpertered -> misinterpreted - jit-on-track: affectionally -> affectionately - jit-on-track: overhwhelming -> overwhelming - meet-team-brett-cannon: spikein -> spike in - python-3100a4: releasee -> release - python-3100a2: releasee -> release - python-3100-is-available: propper -> proper - 2012-language-summit-report: fairlyquick -> fairly quick --- content/posts/2012-language-summit-report/index.md | 2 +- content/posts/jit-on-track/index.md | 6 +++--- content/posts/meet-team-brett-cannon/index.md | 2 +- content/posts/python-3100-is-available/index.md | 2 +- content/posts/python-3100a2-is-now-available-for/index.md | 2 +- content/posts/python-3100a4-is-now-available-for/index.md | 2 +- 6 files changed, 8 insertions(+), 8 deletions(-) diff --git a/content/posts/2012-language-summit-report/index.md b/content/posts/2012-language-summit-report/index.md index 43ad787..1f186d2 100644 --- a/content/posts/2012-language-summit-report/index.md +++ b/content/posts/2012-language-summit-report/index.md @@ -34,7 +34,7 @@ In about two minutes, discussion on PEP [405](http://www.python.org/dev/peps/pep #### PEP 397 Inclusion -Without much of a Windows representation at the summit, discussion was fairlyquick, but it was pretty much agreed that PEP [397](http://www.python.org/dev/peps/pep-0397/) was something we should accept. Brian Curtin spoke in favor of the PEP, as well as mentioning ongoing work on the Windows installer to optionally add the executable's directory to the Path. After discussion outside of the summit, it was additionally agreed upon that the launcher should be installed via the 3.3 Windows installer, while it can also live as a standalone installer for those not taking 3.3. Additionally, there needs to be some work done on the PEP to remove much of the low-level detail that is coupled too tightly with the implementation, e.g., explaining of the location of the py.ini file. +Without much of a Windows representation at the summit, discussion was fairly quick, but it was pretty much agreed that PEP [397](http://www.python.org/dev/peps/pep-0397/) was something we should accept. Brian Curtin spoke in favor of the PEP, as well as mentioning ongoing work on the Windows installer to optionally add the executable's directory to the Path. After discussion outside of the summit, it was additionally agreed upon that the launcher should be installed via the 3.3 Windows installer, while it can also live as a standalone installer for those not taking 3.3. Additionally, there needs to be some work done on the PEP to remove much of the low-level detail that is coupled too tightly with the implementation, e.g., explaining of the location of the py.ini file. #### speed.python.org diff --git a/content/posts/jit-on-track/index.md b/content/posts/jit-on-track/index.md index 6acc9fc..e1a1f31 100644 --- a/content/posts/jit-on-track/index.md +++ b/content/posts/jit-on-track/index.md @@ -47,9 +47,9 @@ The community optimization efforts paid off. The JIT went from 1% faster on x86_ ### Trace recording Again, I attribute a lot of this to luck, but during the CPython core sprints in Cambridge, Brandt nerd-sniped me to rewrite the JIT frontend to a tracing one. I initially didn't like the idea, but as a friendly form of spite-driven-development, I thought I'd rewrite it just to prove to him it didn't work. -The initial prototype worked in 3 days, however it took a month to get it JITting properly without failing the test suite. The initial results were dismal---about 6% slower on x86_64 Linux. I was about to ditch the idea, until a lucky accident happened: I misinterpertered a suggestion given by Mark. +The initial prototype worked in 3 days, however it took a month to get it JITting properly without failing the test suite. The initial results were dismal---about 6% slower on x86_64 Linux. I was about to ditch the idea, until a lucky accident happened: I misinterpreted a suggestion given by Mark. -Mark had suggested earlier to thread the dispatch table through the interpreter, thus having two dispatch tables in the interpreter (one normal interpreter, and one for tracing). Mark suggested we should have the tracing table be tracing versions of normal instructions. However, I misunderstood and came up with an even more extreme version: instead of tracing versions of normal instructions, I had only one instruction responsible for tracing, and all instructions in the second table point to that. Yes I know this part is confusing, I'll hopefully try to explain better one day. This turned out to be a really really good choice. I found that the initial dual table approach was so much slower due to a doubling of the size of the interpreter, causing huge compiled code bloat, and naturally a slowdown. By using only a single instruction and two tables, we only increase the interpreter by a size of 1 instruction, and also keep the base interpreter ultra fast. I affectionally call this mechanism dual dispatch. +Mark had suggested earlier to thread the dispatch table through the interpreter, thus having two dispatch tables in the interpreter (one normal interpreter, and one for tracing). Mark suggested we should have the tracing table be tracing versions of normal instructions. However, I misunderstood and came up with an even more extreme version: instead of tracing versions of normal instructions, I had only one instruction responsible for tracing, and all instructions in the second table point to that. Yes I know this part is confusing, I'll hopefully try to explain better one day. This turned out to be a really really good choice. I found that the initial dual table approach was so much slower due to a doubling of the size of the interpreter, causing huge compiled code bloat, and naturally a slowdown. By using only a single instruction and two tables, we only increase the interpreter by a size of 1 instruction, and also keep the base interpreter ultra fast. I affectionately call this mechanism dual dispatch. There's a lot more that went into the design of the trace recording interpreter. I'm tooting my own horn here, but I truly think it's a mini work of art. It took me 1 week to iterate on the interpreter until it was overall faster. It went from 6% slower to roughly no speedup after using dual dispatch. After that, I stamped out a bunch of slow edge cases in the tracing interpreter to eventually make it 1.x% faster. Tracing the interpreter itself is only 3-5x slower by my own estimations than the specializing interpreter. Key to this is that it respects all normal behavior of the specializing interpreter and mostly doesn't interfere with it. @@ -61,7 +61,7 @@ So I have to thank Brandt and Mark for leading me to stumble upon such a nice so The other lucky bet we made early on was to try reference count elimination. This, again, was work originally by Matt Page done in CPython bytecode optimizer (more details in previous blog post on optimization). I noticed that there was still a branch left in the JITted code per reference count decrement even with the bytecode optimizer work. I thought: "why not try eliminating the branch", and had no clue how much it would help. It turns out a single branch is actually quite expensive and these add up over time. Especially if it's >=1 branch for every single Python instruction! -The other lucky part is how easy this was to parallelize and how great it was a tool to teach people about the interpreter and JIT. This was the main optimization that we directed people to work on in the Python 3.15 JIT. Although it was a mostly manual refactoring process, it taught people the key parts they needed to learn about the JIT without overhwhelming them. +The other lucky part is how easy this was to parallelize and how great it was a tool to teach people about the interpreter and JIT. This was the main optimization that we directed people to work on in the Python 3.15 JIT. Although it was a mostly manual refactoring process, it taught people the key parts they needed to learn about the JIT without overwhelming them. ## Part 3: A great team diff --git a/content/posts/meet-team-brett-cannon/index.md b/content/posts/meet-team-brett-cannon/index.md index 172b459..3a12ae9 100644 --- a/content/posts/meet-team-brett-cannon/index.md +++ b/content/posts/meet-team-brett-cannon/index.md @@ -23,7 +23,7 @@ Since April 2003 (shortly after PyCon 2003). **How did you get started as a core developer? Do you remember your first commit?** -I became a core developer thanks to incessantly bugging people to commit patches for me (a trick that doesn't quite work as well as it used to; perk of getting in before Python's popularity spikein 2003/2004). Starting in August 2002 I revitalized the Python-Dev Summaries (which lasted for about 2.5 years). While writing the Summaries I would fairly regularly pick up on little issues that needed fixing. Since I was already talking on python-dev fairly regularly I simply asked folks to check my patches and commit them for me. One day Guido just asked why I didn't commit myself, I said I didn't have commit rights, and then he more or less said "you do now". +I became a core developer thanks to incessantly bugging people to commit patches for me (a trick that doesn't quite work as well as it used to; perk of getting in before Python's popularity spike in 2003/2004). Starting in August 2002 I revitalized the Python-Dev Summaries (which lasted for about 2.5 years). While writing the Summaries I would fairly regularly pick up on little issues that needed fixing. Since I was already talking on python-dev fairly regularly I simply asked folks to check my patches and commit them for me. One day Guido just asked why I didn't commit myself, I said I didn't have commit rights, and then he more or less said "you do now". As for my first commit (changeset 28686), it was fixing some string escapement in time.strptime() (which happens to be my first contribution to Python itself). diff --git a/content/posts/python-3100-is-available/index.md b/content/posts/python-3100-is-available/index.md index 7127f85..d65648b 100644 --- a/content/posts/python-3100-is-available/index.md +++ b/content/posts/python-3100-is-available/index.md @@ -65,7 +65,7 @@ More resources ## And now for something completely different -For a Schwarzschild black hole (a black hole with no rotation or electromagnetic charge), given a free fall particle starting at the event horizon, the maximum propper time (which happens when it falls without angular velocity) it will experience to fall into the singularity is \`π\*M\` ([in natural units](https://en.wikipedia.org/wiki/Natural_units)), where M is the mass of the black hole. For Sagittarius A\* (the black hole at the centre of the milky way) this time is approximately 1 minute. +For a Schwarzschild black hole (a black hole with no rotation or electromagnetic charge), given a free fall particle starting at the event horizon, the maximum proper time (which happens when it falls without angular velocity) it will experience to fall into the singularity is \`π\*M\` ([in natural units](https://en.wikipedia.org/wiki/Natural_units)), where M is the mass of the black hole. For Sagittarius A\* (the black hole at the centre of the milky way) this time is approximately 1 minute. Schwarzschild black holes are also unique because they have a space-like singularity at their core, which means that the singularity doesn't happen at a specific point in \*space\* but happens at a specific point in \*time\* (the future). This means once you are inside the event horizon you cannot point with your finger towards the direction the singularity is located because the singularity happens in your future: no matter where you move, you will "fall" into it. diff --git a/content/posts/python-3100a2-is-now-available-for/index.md b/content/posts/python-3100a2-is-now-available-for/index.md index e4aa175..bda80bb 100644 --- a/content/posts/python-3100a2-is-now-available-for/index.md +++ b/content/posts/python-3100a2-is-now-available-for/index.md @@ -17,7 +17,7 @@ This is an early developer preview of Python 3.10 # Major new features of the 3.10 series, compared to 3.9 -Python 3.10 is still in development. This releasee, 3.10.0a2 is the second of six planned alpha releases. +Python 3.10 is still in development. This release, 3.10.0a2 is the second of six planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2021-05-03) and, if necessary, may be modified or deleted up until the release candidate phase (2021-10-04). Please keep in mind that this is a preview release and its use is not recommended for production environments. diff --git a/content/posts/python-3100a4-is-now-available-for/index.md b/content/posts/python-3100a4-is-now-available-for/index.md index f1f4c94..3ed1ab9 100644 --- a/content/posts/python-3100a4-is-now-available-for/index.md +++ b/content/posts/python-3100a4-is-now-available-for/index.md @@ -18,7 +18,7 @@ This is an early developer preview of Python 3.10 # Major new features of the 3.10 series, compared to 3.9 -Python 3.10 is still in development. This releasee, 3.10.0a4 is the second of six planned alpha releases. +Python 3.10 is still in development. This release, 3.10.0a4 is the second of six planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2021-05-03) and, if necessary, may be modified or deleted up until the release candidate phase (2021-10-04). Please keep in mind that this is a preview release and its use is not recommended for production environments.