thecompilr

What is dead may never die. Server Push never gained any traction sadly, despite having a great potential.

For me a good analogy to API is driving a car. The interface (API) to the car is the steering wheel, the pedals, and some common controls like signals and the horn.

You only need to learn to drive one car, and you can drive them all. But under the hood the cars are completely different. Gas, diesel, battery, hybrid, all have the same API, yet no one says that you copied a car if it has a steering wheel.

One could probably reinvent the (steering) wheel and possibly make a better interface to the car, but that would result in people having to learn how to drive your car specifically.

Exactly

A small nit that bugs me in the original post

> The difference between AES128 and AES256 appears to be approximately 26%, rather than the 40% one might expect (AES128 does 10 rounds, AES256 does 14 rounds). There may be some limiting factor that prevents AES128 running at the expected speed, or perhaps this CPU has extra area dedicated to making AES256 faster.

The hardware in the CPU performs a single AES round, it does not dedicate more hardware for AES256. One who understands that AES-GCM is not just AES knows that the difference is due to the GCM overhead, that is the same for 128 and 256.

There is user mode wireguard for Linux, it is wireguard-go: https://git.zx2c4.com/wireguard-go/.

There is also BoringTun: https://github.com/cloudflare/boringtun which is faster

Disclaimer: I wrote BoringTun

There is a setting in HTTP/2 called SETTINGS_MAX_CONCURRENT_STREAMS, if set to 1 it works like HTTP/1.1, with no multiplexing. Setting it to 4~8 would make it behave in a similar way a browser actually does with HTTP/1 (creating multiple connections in parallel).

I have been getting the mio question a lot.

Mio, in theory, is not very far off of what I ended up implementing, but it is missing a few features that I really needed, and building those features on top of Mio would be harder than just using epoll/kqueue directly. Also I don't understand the fear people have of using epoll/kqueue. Those are very basic features that every engineer has to know how to use.

So what are the features:

No locks - Mio polls under lock, but epoll/kqueue are multithread safe by nature as long as you use the correct filters. Mio has considerable overhead over pure epoll/kqueue.

No need for tokens, instead I store closure pointers. Real zero overhead. Of course I could cast pointers to usize and use as Mio tokens, but I would still have to build the ownership model on top, which is most of the work anyway.

Timers in Mio run in a thread??? I use platform idiomatic conventions instead, which with kqueue require direct access to kqueue.

Signal handlers, can't make idiomatic one with Mio (or maybe I missed how).

Same with notifications. Could use something awkward like a channel, but prefer idiomatic approach.

Currently the library part supports Windows, and it can be used from C# or C++, if you want to use something like https://docs.microsoft.com/en-us/uwp/api/Windows.Networking....

However there is no native support for tunnel interfaces in Windows, and we are still thinking about the best way to add full support.

The WireGuard project for example developed a whole new driver just for that. Don't know if we are going to follow that route.

It is still quite expensive, the kernel module is still faster. Performance depends a lot on your kernel version and network card. We measured anywhere from 20% to 40% advantage to kernel module. But we are working on additional performance features, such as using send/recvmmsg and raw sockets.

Windows PowerShell is also smooth as butter. After using it for a bit going back to macos or linux terminals feels sluggish.

I have to strongly disagree with Linus here. While he got the history up to this point right, in the present it is very easy to develop for multiple platforms at once.

CI platforms make it super easy.

Cloudflare made a big effort to make all software run on x86 and aarch64, and it wasn't that hard at all. Most things today work out of the box.

Many things that don't work, were not very robust to begin with, and fixing them to work on both platforms only made the software better as a whole.

Cloudflare could move to ARM servers in a days' notice, and would already do that if Qualcomm hasn't closed the Centriq shop.

The only real advantage I see for Intel today is AVX512, which can't be beat for some workloads, SVE would be able to compete for some workloads, but not all. However most workloads don't use vector processing instructions anyway. Still, I hope ARM improves their SIMD architecture further.

As for the ALU performance difference, it is very easy to bridge. As evident by Apple's CPUs and Qualcomm Centriq simply having four ALU units gets you to about the same ALU performance as Intel.

Branch prediction, cache performance and the interconnect are still much better at Intel processors. However Intel already peaked branch prediction performance, so the difference can only get smaller with time.

From the only number I see, the specint score, it is 40% faster than Qualcomm Centriq socket vs socket, and even 6% core vs core. Which is a really great if true. Wonder what the power draw on that thing though.

Symmetric MultiThreading (SMT) - that would be Simultaneous MultiThreading

FWIW at Cloudflare we were running brotli for dynamic content for a while now. However the Cloudflare gzip library is much faster than brotli. You can find a benchmark in here: https://blog.cloudflare.com/arm-takes-wing/

Can't say much changed over the years https://lkml.org/lkml/2003/2/26/158

You could, but the premise of using a tree was to avoid unpredictable rehashing latency, if you start compacting the tree every now and then, you basically pay the same price.

Thank you. Exactly. Even worse each node could live in a different page. Hash maps can span multiple pages, but the lookup should succeed in 1 or 2 tries for a good hash function.

Depending on implementation and usage, radix trees can get extremely segmented, slowing down significantly over time.

Yeah, but with the side effect of clearing the flag registers. So can't be used between operations that rely on flags. Alternatively it is great to break false flag dependency.

You imply that there is a delay between the promise and the push, but it is not necessarily so. In fact the promise and the data may be sent in the same packet.

jpegtran does not transcode. It performs lossless optimization of the Huffman coefficients.

Yes and no. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....

> The ARM Advanced SIMD architecture, its associated implementations, and supporting software, are commonly referred to as NEON technology. There are NEON instruction sets for both AArch32 (equivalent to the ARMv7 NEON instructions) and for AArch64. Both can be used to significantly accelerate repetitive operations on large data sets. This can be useful in applications such as media codecs.

The NEON architecture for AArch64 uses 32 × 128-bit register, twice as many as for ARMv7. These are the same registers used by the floating-point instructions. All compiled code and subroutines conforms to the EABI, which specifies which registers can be corrupted and which registers must be preserved within a particular subroutine. The compiler is free to use any NEON/VFP registers for floating-point values or NEON data at any point in the code.

I don't think Intel is going to die anytime soon, but I do hope for a stronger competition between ARM based server, Intel and AMD.

> which will run circles around anything arm based.

Do you have a single number to back that up?

I don't even claim that ARM is better than Intel on SIMD workloads. Quite the opposite. Intel has AVX2 and AVX512 that rip ARM apart on most highly parallel workloads. This very specific snippet benefits a bit more from ARM SIMD due to the presence of specific instructions lacking in SSE. But AVX512 has so much more instructions, with a much wider application.

Our jpegtran is still faster. We use libjpegturbo for other manipulations though.

I ended up writing asm for the important part:

https://github.com/cloudflare/jpegtran/blob/vlad/arm/jchuff_...

Intel encourages employees to file all sorts of crappy patents, but I don't see it as a bad or evil practice, but rather as a defensive strategy. Meaning that they don't really enforce patent usage on others, instead they need to have a trove of own patents as defense against patent trolls.

Encryption is one thing Intel has a lead in, both in single thread, and as a platform. But even there QC is sufficiently fast, and crypto although extensively used actually uses very little CPU. https://blog.cloudflare.com/how-expensive-is-crypto-anyway/

Those are indeed workloads, specific for a webserver and even more specific for CF. Many other workloads that we don't care about that Intel can handily win of course. We don't have use for most Intel extensions, like AVX512 and barely use any AVX2. Intel is the king of HPC and single threaded performance for a few more years. Although ARM can potentially leapfrog Intel in the HPC space, if someone implements the Salable Vector Instruction extension in 1024 or 2048 bit.