eis

The classic example of a changing workload is a database which has a normal workload that maybe resembles a zipf or bell distribution but then someone runs exports which do full scans over large parts of the DB. These changes in workloads can be intermittent but they exist. A very similar change in workload that is well known is the pagecache for filesystems (e.g. backup doing full scan over disk and evicting everything from the cache) which is why admission policies were invented in the first place. So you have two different algorithms already. Just maybe not adaptive.

A friend of mine works on a online-shop / distribution system that during most of the day has a zipf like distribution but after normal working hours when retail shops close he gets completely different patterns as the shops push their data for the day into the system and then all kinds of BI tools run for a few hours.

Of course adaptive caches are never completely optimal because it takes time for them to learn which workload is actually currently happening but after a while they can get very close. A good adaptive cache should not need tuning to get good results because the whole reason for it to be adaptive is to tune itself. Of course there are quite a few adaptive caches, especially the first ones that pioneered this, that still needed tuning.

I don't understand the last question. You say you can't see how FIFO can fail catastrophically and at the same time state a case how it can. Scanning workloads are something that does show up in the real world all the time. NovaX seems to have run your algorithm through some traces where it had a near zero hitrate. It can be more important to avoid these extreme cases than having a slightly better hitrate in the normal case.

I can't agree with that. More sophisticated algorithms don't necessarily have to make things worse. In fact I think the opposite is true. Simple algorithms are the ones most likely to fail catastrophically because they are made for a certain range of access patterns.

You don't always know the workload beforehand and can pick the appropriate cache policy. Workloads can even change during runtime.

I haven't seen a simple cache algorithm that performs well in every workload and I believe any that wants to succeed needs to incorporate different sub-algorithms for different workloads and be adaptive.

Ok I see where the difference is now. You are clearing the hit bit for all items marked as hit on a single eviction. I mean yes I guess that means that during the following request you don't have to check all items in the queue but now you have a different problem: you evict items prematurely. With a cache of size 2 I can't show it but consider a cache of size 3 and the following pattern: a, a, b, b, c, b, d, e

When d arrives state changes c(0) b(1) a(1) -> d(0) c(0) b(0). When e arrives state changes d(1) c(0) b(0) -> e(0) d(0) c(0).

Note how b got evicted from the cache even though it was requested more recently and more frequently than c because d cleared out the hit bit for both b and c.

Now you traded off hitrate vs latency. But the worst case latency is still O(n) just can't happen multiple times in a row anymore.

Imagine you have a cache of 1 million items all marked as hit and you get a new request which would evict all 1 million items. You gained latency for some subsequent requests but increased it in the current one. Crucially you also just cleared out the hit marker of whole cache.

It might not happen only once in a while. Consider the following pattern in which a Fetch() does a Get and then an Insert on cach-miss:

   Fetch("1"); Fetch("1"); Fetch("2"); Fetch("2"); Fetch("3"); Fetch("3"); ...

This will result in your queue being 100% filled with items that are marked as hit because of the second Fetch for each key. After the queue is full each first Fetch will result in an eviction (new key to insert) which has to walk the whole queue because the only item marked not-hit is at the head of the queue due to being lazy promoted.

My O(n*m) reply was because your O(m) was considering a whole run over multiple requests and my O(n) was only considering one request. So if I were to also talk about multiple requests then your eviction algorithm needs to look at O(n*m) items for evictions in the example pattern I presented. O(n) per request for m requests.

A malicious actor could abuse this fact to cause a DoS.

No you can't just bound the number of objects it checks because that would result in a flurry of cache misses as it would mean you have to fail the insert.

I think we are not talking about the same thing. LRU needs to access/modify the tail and head of the queue once per request for both Get and Insert.

Your algorithm on the other hand does not need to modify the order of the queue on a Get (just mark single item as hit if not marked already) which is really good. But on Insert your algorithm needs to do a reverse scan through the queue until it finds an item it can evict (not marked as hit). This might need to walk the whole queue if unlucky. And it can get so bad that it needs to do that on every single eviction so latency and CPU usage could skyrocket. Granted, this is a worst case scenario that shouldn't happen usually but if it does then it could be a real problem.

So in that sense LRU would be O(m) in terms of queue modifications and reads but yours would be O(n*m) for queue reads.

The O(n) I mentioned was for the number of items the algorithm needs to check on a single insert that results in an eviction aka the usual case.

It looks like your lazy promotion algorithm is O(n). If you get a particularily unlucky request pattern you'll be walking the whole list to know which item to evict. I don't think the claim that this LP FIFO method is always less intensive than LRU will hold up to scrutiny. But I still find the paper inspiring. Thanks for shaking a bit the established believes in the field :)

I'm sorry for the negativity but the design is awful for a dashboard. Weird distracting animations (graphs wiggle on hover), the lines are janky due to the cartoonish draw style. No clearly visible separations between the stats and an annoying background texture over the whole page that actually could make sense as a grid if only things were aligned to the grid. It also feels slightly sluggish on my laptop.

I just had a brief read of the protocol but my understanding is yes, there is nothing like onion routing or similar that could disguise to a peer that is serving the data that the requester is indeed the one who is interested in it.

Seems like it took IMDB with it. Surprised that Amazon is not able to keep their own property up when one of their zones goes down. Not a great example.

I am sure there are examples where JPEG XL outperforms AVIF. But looking through all those images in the test sample I get the impression that AVIF on average in the lowest quality setting is significantly better than JPEG XL.

I agree that the example you presented indeed has the mentioned shadow issue in AVIF.

Interestingly in the latest FF on Linux for some reason for me the colors are washed out for AVIF and JPEGXL but not the other formats. Looking fine in Chromium though.

When zooming in 3x I can say that AVIF looks significantly better than JPEGXL in the lower quality settings while being consistently a little bit smaller in filesize. There is better color retention, less noise and looks sharper. At the "tiny" setting the difference is night and day. At the highest setting they are so close enough that I wouldn't say there's a clear winner for me after going through all the images.

I think it would be great if the homepage could have a prominent link to the documentation as it wasn't obvious to me where to find it. I followed the link to Github which in the readme has a howto for building the project and there is a docs folder which has a few documents mostly with dealing how to get started contributing.

In the end I think a good entry seems to tbe the Wiki on Github: https://github.com/servo/servo/wiki

I would also love to have a clear overview page that shows a high level view of the state of the engine in terms of feature support/completeness.

I'd love to see the project getting revitalized and gain traction now that it is outside Mozilla and maybe maybe eventually a new phoenix might rise.

Is there something noteworthy about this specific incident? Faults of this magnitude are unfortunately relatively common. For example earlier this month there was a 6.2 quake not far from this one on the coast of the other side of Japan. I don't expect major damage or deaths, hopefully.

I really hope Linux can get a modern FS into common usage (as in default FS for most distros). After more than a decade ZFS and BTRFS didn't go anywhere. Something that's just there as a default, is stable, performs decently (at least on ext4 level) and brings modern features like snapshots. Bcachefs seems to have a decent shot.

What I'd like to see even more though would be a switch from the existing posix based filesystem APIs to a transaction based system. It is way too complicated to do filesystem operations that are not prone to data corruption should there be any issues.

I guess even a psychopath might leave a tip at a restaurant. Things rarely are 100% bad but those nuances should also not distract from the big picture.

It's totally fair for employees to ask for more salary or leave especially if the company is raking in high profits but I think it's absurd to have a tipping system in an Apple retail shop. Maybe maybe I could make sense of a tip for a support request where the clerk goes the extra mile but in the unions system the tip is then spread amongst all members of the union.

   > Finally, the union is asking Apple to pay $1 an hour more to employees who become first-aid certified

If Apple wanted their retail staff to be first-aid certified then they could just require that. I don't see why Apple would want it so much that they'd pay $1 an hour for it.

I am not familiar with union negotiations. Is this a case of "we ask for a bit of over the top or outlandish things which we'll then give up in order to make it easier to score the main points"?

   > I don't have a CloudFlare account so I wrote up a detailed post on their community forums. I offered a HAR file and was willing to do diagnostics. It received no responses and it was auto-closed.

Cloudflare has some weird thing going on there if you want to report bugs. If you try to open a support request to report the bug it'll be auto-closed stating only paid accounts can submit support tickets. Then it says if you really are sure then post it in the community. Did that but the post was auto deleted as spam. All I was trying to do was report a bug in their dashboard. Did someone internally game the KPI for open support issues? :)

It's probably very hard to shrink further than a very low number of atoms but we're far from that. The "2nm" marketing name has no relation to the actual physical size of the transistors. The physical features of the "3nm" process node are something like 24nm and 48nm. The Van der Waals radius of a silicon atom is about 0.2nm. Transistors made from a single molecule have been demostrated. Maybe we could even shrink to elementary particles but that's in the realm of SciFi so far.

According to some reports it might be both. N3 (aka N3B) for A17 and N3E for M3. N3E is probably too late to produce the numbers needed for the A17 which should hit the market in September.

Unfortunately TSMC does indeed use nm extensively https://www.tsmc.com/english/dedicatedFoundry/technology/log...

Taiwan made the foundry business a strategic priority for multiple reasons. Intel at least for the US was always a business with national security impact. Europe never realized the importance and didn't make it anywhere near priority. They did not provide enough on-going incentives nor did they protect their companies from being sold to foreign ones. Instead the companies jumped hard on the outsourcing train and pushed as much manufacturing abroad as possible. This was a very shortsighted move that temporarily increased profits but traded the future for it. When nation-states put their weight behind something then it's nearly impossible to compete unless your own nation-state puts their weight behind you as well.

There is still some chance for Europe to come back into it but I have doubts they'll find the will to do it.

Intels Fab 24 in Ireland does 14nm at least. But yea, Europe really missed the boat hard on chip manufacturing even though they have ASML sitting in the Netherlands. Actually they already were in the game with several fabs. And then there was ARM. Feels like they not just missed the boat but mismanaged and then sold it for scraps while they could have had a realistic shot of being at the top of the game. Sigh.

As with most things in the beginning a lot of low hanging fruit allow for rapid innovation and progress. As things become more developed, progress tends to slow. At that time both hardware and software made rapid progress.

I think currently the big change that is happening is path based ray tracing. In the next couple years a lot of mainstream hardware should be able to do it and it makes a big impact on how games look.

Apart from that it's just more triangles I guess. We are approaching photorealistic looks and further development will try to run what huge desktop graphics cards can do, on smartphone GPUs. There we have seen actually significant developments in the past 10 years.

I just did the update on a workstation of mine. During the update to 23.04 the Firefox snap was downgraded from 112.0.1-1 (latest/stable) to 111.0.1-2 (latest/stable/ubuntu-23.04). When trying to start Firefox after the reboot it will detect the downgrade and in order to prevent data corruption offer two choices: create a brand new user profile or quit. Oh Canonical, the Firefox snap fun never ends.

Yes but what a reader unfamiliar with the server auction at Hetzner should know is that there is very limited supply (and sometimes none) plus it's outdated hardware. At this very moment I see 9 servers with 1080 priced between 105 and 118 euro per month available.

Additional benchmarks:

sysbench memory --time=60 --threads=4 run

   AMD64: 5859951.00 per second
   ARM64: 6052749.14 per second

Here ARM had a lead.

Next up I timed compiling nodejs. time make -j4. I ran the test two times and took the faster result for each.

   AMD64: 
      real    28m46.385s
      user    107m48.971s
      sys     5m12.994s
   ARM64:
      real    39m18.443s
      user    146m25.801s
      sys     7m53.271s

Here ARM seems to be roughly 36% slower. This is actually pretty good considering the price difference.

Rescaled the ARM VM to 8 vCPUs:

      real    22m20.624s
      user    162m30.176s
      sys     8m50.104s

So now the ARM offering is noticably faster than the AMD instance but still cheaper. 12.49 Eur vs 13.60 Eur.

What I learn from these benchmarks is that you might get some really good value out of these ARM instances if your usecase is not impacted all too much in terms of performance.

Hetzner at some point used to offer dedicated servers with GPUs like a nVidia 1080 but stopped offering these because there was a lot of fraud and abuse involving crypto miners.

With all the AI hype I'd assume they'll try to offer GPU instances again with precautions put in place.

Yes and we might never know or maybe it's not even static.

This will never be 100% scientific or correct since there are many factors that come into play, stuff like noisy neighbour for example.

What I'm trying to get is a ballpark idea of how their arm vCPU compares to the amd equivalent.

Great news. I'd like to see how a vCPU compares between arm64 and amd64 but not sure how to best go about it. I've created VMs for both with 4 vCPU and will run the phoronix benchmark suite. After that I'll probably try 16 arm vs 8 amd vCPU because that's a closer match in terms of price. Any suggestions welcome but I also don't want to spend too many hours on it. Will post results.

Ran the kernel build benchmark (result is seconds, lower is better):

   AMD64:
        272.916
        273.128
        270.477
   ARM64:
        1011.799
        1004.713
        1015.261

So the ARM CAX21 instance for 6.49 EUR/month took roughly 3.7x as long as the AMD CPX31 instance which costs 13.60 EUR/month. A roughly 2.1x price difference. Here the ARM instance did not shine in a kernel-compile-per-eur metric.

Also ran sysbench cpu --time=60 --threads=4 run

   AMD64: events per second: 14681.70
   ARM64: events per second: 13455.11

In this test the both are very close.