I remember back in 2000 ish I worked in R&D of a PC manufacturer and had to check the new PSUs and cases with a 'Test Finger' to make sure all the holes were small enough. The test finger was really expensive IIRC.
What is surprising is that a 14kB page can load much faster than a 15kB page — maybe 612ms faster — while the difference between a 15kB and a 16kB page is trivial.
Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses. Implementations MUST either use pacing or limit such bursts to the initial congestion window, which is recommended to be the minimum of 10 * max_datagram_size and max(2* max_datagram_size, 14720)), where max_datagram_size is the current maximum size of a datagram for the connection, not including UDP or IP overhead.
A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.
Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.
另外一條路是在 TCP 連線時透過 HTTP header 告訴瀏覽器升級：
An HTTP origin can advertise the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame ([ALTSVC]) using the "h3" ALPN token.
像是這樣：
Alt-Svc: h3=":50781"
然後 client 就可以跑上 HTTP/3：
On receipt of an Alt-Svc record indicating HTTP/3 support, a client MAY attempt to establish a QUIC connection to the indicated host and port; if this connection is successful, the client can send HTTP requests using the mapping described in this document.
Q. Is there a separate charge for enabling HTTP/3?
No, there is no separate charge for enabling HTTP/3 on Amazon CloudFront distributions. HTTP/3 requests will be charged at the request pricing rates as per your pricing plan.
If you're running an Apple Silicon Mac you can get an early build of Teams osx-arm64 from the exploration build link listed here.[0]
I've been running a daily build for a few weeks and it's noticeably better than the Intel build on an M1 Pro. It launches in half the time and feels far more responsive (probably due to not needing to use the Rosetta JIT for Electron). That said it's still a daily "exploration" build so YMMV.
How do you prevent it from automatically updating to the Intel version? I keep downloading the preview builds and they keep getting updated.
後面還有看到有人說他直接實體隔離，把這些肥滋滋的 app 跑在另外一台 Mac 上，然後透過 Universal Control 使用，大多數的情況下都夠用，真的有需要分享畫面時再跑在自己機器上，用完就可以關掉：
Thanks for the tip. I'll give this a try!
For work, I have to run Microsoft Teams, Slack, and Discord. Of those 3, Slack surprisingly uses the least amount of memory (~700 MB), and Teams uses the most (~1.5 GB). I dusted off an old Intel Mac (literally) and interact with it using Universal Control. It only runs those 3 chat apps + mail. It's turned out to be a great way to offload resource hogs and as an added benefit, it minimizes distractions. I'll occasionally glance at the dock to see if there are any notification badges, whereas on my main Mac, I'd feel compelled to deal with notifications immediately.
When I have to share my screen or focus on a conversation, I'll fire up one of those 3 apps on my main (M1) Mac and quit it when I'm done.
Universal Control still feels rough around the edges, but it has saved me from ditching my Macbook Air and shelling out for an M1 Macbook Pro. Sometimes there are issues with reconnecting to the Intel Mac, but it seems to resolve itself if I wait a bit or turn off/on wifi.
It turns out that Chrome actively throttles requests, including those to cached resources, to reduce I/O contention. This generally improves performance, but will mean that pages with a large number of cached resources will see a slower retrieval time for each resource.
For these tests, we used a custom configuration file. We first deliberately set the buffer pool size to around 10% of the total database size in order to increase I/O-bound load. The database size was 2358MB, so we set our buffer pool size to 256MB. We then increased the buffer size to 16384MB to see what happens when Docker isn’t bound by I/O load.
首先是在 -O3 的情況下 (也就是作者使用的參數)，可以看到類似的結果：(我桌機的 CPU 是定速，沒有跑動態調整)
$ repeat 10 ./a
[-] Took: 248830 ns.
[-] Took: 249150 ns.
[-] Took: 248760 ns.
[-] Took: 248730 ns.
[-] Took: 248770 ns.
[-] Took: 248861 ns.
[-] Took: 248760 ns.
[-] Took: 253050 ns.
[-] Took: 248640 ns.
[-] Took: 249211 ns.
$ repeat 10 ./b
[-] Took: 686660 ns.
[-] Took: 696090 ns.
[-] Took: 696310 ns.
[-] Took: 694431 ns.
[-] Took: 691971 ns.
[-] Took: 697690 ns.
[-] Took: 693241 ns.
[-] Took: 692900 ns.
[-] Took: 654751 ns.
[-] Took: 679101 ns.
從版本 A 的 objdump -d -S -M intel a 可以看到作者 screenshot 內也有看的 unroll 與 SSE2 指令集：
$ repeat 10 ./a
[-] Took: 571140 ns.
[-] Took: 570280 ns.
[-] Took: 571271 ns.
[-] Took: 573971 ns.
[-] Took: 571981 ns.
[-] Took: 569650 ns.
[-] Took: 566361 ns.
[-] Took: 571600 ns.
[-] Took: 571330 ns.
[-] Took: 571030 ns.
$ repeat 10 ./b
[-] Took: 697521 ns.
[-] Took: 696961 ns.
[-] Took: 696201 ns.
[-] Took: 694921 ns.
[-] Took: 696930 ns.
[-] Took: 695001 ns.
[-] Took: 701661 ns.
[-] Took: 698100 ns.
[-] Took: 702430 ns.
[-] Took: 702641 ns.
從 objdump 可以看到版本 A 的變化，退化成一次只處理一個，但把所有的數字都用 xmmN 存放計算：
$ repeat 10 ./a
[-] Took: 1097091 ns.
[-] Took: 1092941 ns.
[-] Took: 1092501 ns.
[-] Took: 1091991 ns.
[-] Took: 1092441 ns.
[-] Took: 1093970 ns.
[-] Took: 1091341 ns.
[-] Took: 1093931 ns.
[-] Took: 1094111 ns.
[-] Took: 1092231 ns.
$ repeat 10 ./b
[-] Took: 2703282 ns.
[-] Took: 2705933 ns.
[-] Took: 2703582 ns.
[-] Took: 2702622 ns.
[-] Took: 2703043 ns.
[-] Took: 2702262 ns.
[-] Took: 2703352 ns.
[-] Took: 2703532 ns.
[-] Took: 2703112 ns.
[-] Took: 2702533 ns.
When taking the geometric mean of all the Python benchmarks I carried out for this article on the AMD Ryzen 9 5950X, Python 3.11 Beta was about 41% faster overall than the current Python 3.10.4 stable release or 45% over the aging Python 3.8 series.
