Hasnain says:

As an HN commenter alludes, this is why hashmaps should explicitly always randomize iteration order (at least in test mode) so people don’t rely on this behavior. It was surprising how many bugs shook out when we did this at FB

“Thanks to CxByte, Gunnar, Andrew and Brian for their help with debugging this, and their helpful tips. Gunnar in particular was the one who uncovered this bug, and despite my satirical jab in the commit message helped uncover this very interesting bug, so he’s the one who made this post possible.

Also, thanks to the person who introduced this bug (the commit log gets a little fuzzy, so I’m not quite sure who did) and hope he buys a lottery ticket. :^)”

Hasnain says:

Kept nodding while reading this.

“Healthy laziness begets agility - you have way less code, less systems, less everything, and therefore way more ability to maneuver and actually change things with a small number of motivated people - and there’s always a small number of motivated people in any place, and this place might even keep them, if they learn to bargain for raises. And you also don’t need to grow as much, because you don’t need to be adding people to take care of all these sprawling systems that you quickly come to depend on.”

Hasnain says:

“All this provides a read-only SQL queryable data in a single file representing OpenStreetMap metadata. The project evolved from merely transferring format migration to optimizing it for efficient search. This highlights the importance of iterative refinement and the power of combining different technologies to solve problems.”

Hasnain says:

“During the COVID-19 pandemic, when millions of professionals suddenly began working from home, some employers rolled out software that captured screenshots of their employees’ computers and algorithmically scored their productivity. It’s easy to imagine how the current boom in generative AI could build on these foundations: For example, large language models could digest every email and Slack message written by employees to provide managers with summaries of workers’ productivity, work habits, and emotions. These types of technologies not only pose harm to people’s dignity, autonomy, and job satisfaction, they also create information asymmetry that limits people’s ability to challenge or negotiate the terms of their work.

We can’t let it come to that. The battles that gig workers are fighting are the leading front in the larger war for workplace rights, which will affect all of us. The time to define the terms of our relationship with algorithms is right now.”

Hasnain says:

“Their assessment of the resultant reality is equally dark: Respondents describe Israeli actions in damning terms, with 41% saying they constitute major war crimes akin to genocide, nearly 34% saying they constitute genocide, and 16% saying they are not akin to genocide, but are still major war crimes. While these views may seem surprising, they are not markedly different from the views of some segments of the American public, especially Democrats, with one recent poll showing a majority of Democrats saying Israeli actions amounted to genocide.”

Hasnain says:

Yay for caches. And simplicity.

“We demonstrate that a cache often experiences a higher one-hit-wonder ratio than common full trace analysis. Our study on 6594 traces reveals that quickly removing one-hit wonders (quick demotion) is the secret weapon of many advanced algorithms. Motivated by this, we design S3-FIFO, a Simple and Scalable cache eviction algorithm composed of only Static FIFO queues. Our evaluation shows that S3-FIFO achieves better and more robust efficiency than state-of-the-art algorithms. Meanwhile, it is more scalable than LRU-based algorithms.”

Hasnain says:

“Since synchronization is literally built into the database, it’s very tempting to use the Database and the transactions they provide as the synchronization point for EVERYTHING. I would advise caution here, because the database is an expensive part of; and often is THE MOST EXPENSIVE part of your infrastructure. It’s better suited for storing bits on disk, than for synchronizing all of the things for you. If you rely on the DB for synchronization, you will inevitably need to shard and rebalance your database in order to continue scaling, and BTW, you are scaling the most expensive part of your infra.”

Hasnain says:

“That should be most of it. I mean, there are special initialization rules for static variables (constant initialization included), but, like, do you really care? In my humble opinion, here’s the key takeaway: just write your own fucking constructors! You see all that nonsense? Almost completely avoidable if you had just written your own fucking constructors. Don’t let the compiler figure it out for you. You’re the one in control here. Or is it that you think you’re being cute? You just added six instances of undefined behaviour to your company’s codebase, and now twenty Russian hackers are fighting to pwn your app first. Are you stupid? What’s the matter with you? What were you thinking? God.”

Hasnain says:

“TL;DR The code from the tutorial is available at matmul.c. This blog post is the result of my attempt to implement high-performance matrix multiplication on CPU while keeping the code simple, portable and scalable. The implementation follows the BLIS design, works for arbitrary matrix sizes, and, when fine-tuned for an AMD Ryzen 7700 (8 cores), outperforms NumPy (=OpenBLAS), achieving over 1 TFLOPS of peak performance across a wide range of matrix sizes.”

Hasnain says:

This is how we measured the success of this critical project:

* Not a single production incident, given how critical money movement is for Uber
* We didn’t have to rollback the migration for a single table
* We backfilled 250 billion unique records and not a single data inconsistency has been detected so far, with the new architecture in production for over 6 months
* Our new data model reduced complexity in the query path, and we observed latency improvements in both read and write path on Docstore
* The project also resulted in technology consolidation, reducing external dependencies

From a business impact perspective, operating LedgerStore is now very cost effective due to reduced spend on DynamoDB. The estimated yearly savings are $6 million per year, and we also laid the foundation for such other future initiatives.