# CAS Published articles for CAS. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Migrating the Hub from Git LFS to Xet DevFeed: [Migrating the Hub from Git LFS to Xet]() Original publisher: [Read original article]() Author: Jared Sulzdorf; Joseph Godlewski; Sam Horradarn Published: 2025-07-15T00:00:00Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [xet](), [migration](), [content addressed store](), [content defined chunking](), [Amazon S3](), [Git](), [Open Source]() Tags: [cas](), [content-addressed-store](), [content-defined-chunking](), [git](), [infrastructure](), [integration](), [migration](), [s3](), [storage](), [xet]() ### AI overview The article explains Hugging Face's migration of the Hub from Git LFS to Xet. It describes the Git LFS Bridge, background content migrations, content-defined chunking, the content addressed store, and S3-backed storage that enable gradual, large-scale migration without disrupting users. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## From Chunks to Blocks: Accelerating Uploads and Downloads on the Hub DevFeed: [From Chunks to Blocks: Accelerating Uploads and Downloads on the Hub]() Original publisher: [Read original article]() Author: Jared Sulzdorf; yuchenglow; Zach Nation; saba noorassa Published: 2025-02-12T00:00:00Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [hugging face](), [xet](), [content addressed store](), [AI, ML & Data Engineering](), [Open Source](), [Amazon S3]() Tags: [cas](), [collaboration](), [content-addressed-store](), [content-defined-chunking](), [dedupe](), [hugging-face](), [integration](), [network](), [performance](), [quantization](), [rust](), [s3](), [storage](), [xet]() ### AI overview Hugging Face's Xet team explains how content-defined chunking is being adapted for production to accelerate uploads and downloads on the Hub. The article describes the trade-offs of fine-grained deduplication, including network, infrastructure, metadata, and storage costs, and introduces a Rust-based chunk-oriented integration designed to improve experimentation and collaboration on models and datasets. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## On Generating Identity Hash Codes DevFeed: [On Generating Identity Hash Codes]() Original publisher: [Read original article]() Author: Alimate Published: 2020-07-15T00:00:00Z Content type: tutorial Language: en Sources: [Ali Dehghan - Kemikit]() Topics: [Java](), [Randomizer](), [Algorithms, Complexity](), [Concurrency](), [Benchmark]() Tags: [algorithm](), [benchmark](), [cas](), [generate](), [hash](), [java](), [jvm](), [memory](), [retry](), [threads]() ### AI overview This tutorial explains how the HotSpot JVM generates identity hash codes in Java. It examines several strategies, including Park-Miller/Lehmer random number generation, memory-address-based values, a constant value, and sequential numbers, while discussing atomic updates and contention. ### Source excerpt Have you ever wondered how does the HotSpot JVM generate identity hashcodes? ## Introducing Conditional REST Requests DevFeed: [Introducing Conditional REST Requests]() Original publisher: [Read original article]() Author: Casey Rogers Published: 2017-07-31T00:00:00Z Content type: news Language: en Sources: [Firebase Blog]() Topics: [Firebase](), [Realtime Database](), [REST API](), [content addressed store](), [HTTP](), [Transactions]() Tags: [api](), [cas](), [firebase](), [http](), [launch](), [news](), [realtime-database](), [rest](), [updates]() ### AI overview Firebase introduces conditional REST requests for the Realtime Database. Using ETags and the If-Match header, clients can safely perform compare-and-swap updates and retry when another user changes the data first. ### Source excerpt News, tutorials, and updates from the Firebase team. ## You Can Do Any Kind of Atomic Read-Modify-Write Operation DevFeed: [You Can Do Any Kind of Atomic Read-Modify-Write Operation]() Original publisher: [Read original article]() Author: Jeff Preshing Published: 2015-04-02T11:20:00Z Content type: tutorial Language: en Sources: [Jeff Preshing]() Topics: [Code](), [Concurrency](), [Concurrent Programming](), [cpu]() Tags: [atomic](), [cas](), [code](), [concurrent](), [cpu](), [implementation](), [lock-free](), [shift-left](), [thread](), [xor]() ### AI overview This article explains how to implement arbitrary atomic read-modify-write operations in C++11 using compare-and-swap loops. It covers lock-free behavior, the role of CPU instructions, and the challenges of concurrent modifications. ### Source excerpt Atomic read-modify-write operations - or "RMWs" - are more sophisticated than atomic loads and stores. They let you read from a variable in shared memory and simultaneously write a different value in its place. In the C++11 atomic library, all of the following functions perform an RMW: std::atomic<>::fetch_add() std::atomic<>::fetch_sub() std::atomic<>::fetch_and() std::atomic<>::fetch_or() std::atomic<>::fetch_xor() std::atomic<>::exchange() std::atomic<>::compare_exchange_strong() std::atomic<>::compare_exchange_weak() fetch_add, for example, reads from a shared variable, adds another value to it, and writes the result back - all in one indivisible step. You can accomplish the same thing using a mutex, but a mutex-based version wouldn't be lock-free. RMW operations, on the other hand, are designed to be lock-free. They'll take advantage of lock-free CPU instructions whenever possible, such as ldrex/strex on ARMv7. A novice programmer might look at the above list of functions and ask, "Why does C++11 offer so few RMW operations? Why is there an atomic fetch_add, but no atomic fetch_multiply, no fetch_divide and no fetch_shift_left?" There are two reasons: Because there is very little need for those RMW operations in practice. Try not to get the wrong impression of how RMWs are used. You can't write safe multithreaded code by taking a single-threaded algorithm and turning each step into an RMW. Because if you do need those operations, you can easily implement them yourself. As the title says, you can do any kind of RMW operation! Compare-and-Swap: The Mother of All RMWs Out of all the available RMW operations in C++11, the only one that is absolutely essential is compare_exchange_weak. Every other RMW operation can be implemented using that one. It takes a minimum of two arguments: shared.compare_exchange_weak(T& expected, T desired, ...); This function attempts to store the desired value to shared, but only if the current value of shared matches expected. It return ## Further Adventures With CAS Instructions And Micro Benchmarking DevFeed: [Further Adventures With CAS Instructions And Micro Benchmarking]() Original publisher: [Read original article]() Author: Martin Thompson (noreply@blogger.com) Published: 2013-01-25T17:59:00Z Content type: article Language: en Sources: [Mechanical Sympathy]() Topics: [benchmarking](), [Hardware](), [intel](), [x86](), [Concurrency](), [Java]() Tags: [assembly](), [benchmarking](), [cas](), [hardware](), [intel](), [java](), [latency](), [performance](), [techniques](), [x86]() ### AI overview This article revisits apparent CAS and LOCK instruction performance differences between Intel Sandy Bridge and Nehalem processors. It explains that the original microbenchmark partly measured fairness rather than throughput and examines alternative atomic-increment testing using lock xadd. ### Source excerpt In a previous article I reported what appeared to be a performance issue with CAS/LOCK instructions on the Sandy Bridge microarchitecture compared to the previous Nehalem microarchitecture. Since then I've worked with the good people of Intel to understand what was going on and I'm now pleased to be able to shine some light on the previous results. I observed a small drop in throughput with the uncontended single-thread case, and an order-of-magnitude decrease in throughput once multiple threads contend when performing updates. This testing spawned out of observations testing Java Queue implementations and the Disruptor for the multi-producer case. I was initially puzzled by these findings because almost every other performance test I applied to Sandy Bridge indicated a major step forward for this microarchitecture. After digging deeper into this issue it has come to light that my tests have once again fallen fowl of the difficulties in micro-benchmarking. My test is not a good means of testing throughput and it is actually testing fairness in a roundabout manner. Let's revisit the code and work through what is going on. Test Code #include #include #include #include typedef unsigned long long uint64; const uint64 COUNT = 500 * 1000 * 1000; volatile uint64 counter = 0; void* run_add(void* numThreads) { register uint64 value = (COUNT / *((int*)numThreads)) + 1; while (--value != 0) { __sync_add_and_fetch(&counter, 1); } } void* run_xadd(void*) { register uint64 value = counter; while (value < COUNT) { value = __sync_add_and_fetch(&counter, 1); } } void* run_cas(void*) { register uint64 value = 0; while (value < COUNT) { do { value = counter; } while (!__sync_bool_compare_and_swap(&counter, value, value + 1)); } } void* run_cas2(void*) { register uint64 value = 0; register uint64 next = 0; while (value < COUNT) { value = counter; do { next = value + 1; value = __sync_val_compare_and_swap(&counter, value, next); } while (value ## Adventures with AtomicLong DevFeed: [Adventures with AtomicLong]() Original publisher: [Read original article]() Author: Martin Thompson (noreply@blogger.com) Published: 2011-09-11T11:46:00Z Content type: article Language: en Sources: [Mechanical Sympathy]() Topics: [Concurrency](), [Concurrent Programming](), [Java](), [Benchmark](), [intel](), [Programming]() Tags: [atomic](), [benchmark](), [c-plus-plus](), [cas](), [concurrent](), [disruptor](), [intel](), [java](), [performance]() ### AI overview This article examines AtomicLong-based event sequencing in Java's Disruptor and reports unexpectedly worse performance after removing megamorphic method calls. The investigation attributes the result to increased contention exposing a performance issue with atomic instructions on Intel Sandy Bridge processors, also observed in ArrayBlockingQueue. ### Source excerpt Sequencing events between threads is a common operation for many multi-threaded algorithms. These sequences could be used for assigning identity to orders, trades, transactions, messages, events, etc. Within the Disruptor we use a monotonic sequence for all events which is implemented as AtomicLong incrementAndGet for the multi-threaded publishing scenario. While working on the latest version of the Disruptor I made some changes which I was convinced would improve performance, however the results surprised me. I had removed some potentially megamorphic method calls and the performance got worse rather than better. After a lot of investigation, I discovered that the megamorphic method calls were hiding a performance issue with the latest Intel Sandybridge processors. With the megamorphic calls out of the way, the contention on the atomic sequence generation increased exposing the issue. I've also observed this performance issue with other Java concurrent structures such as ArrayBlockingQueue. I've been running various benchmarks on Sandybridge and have so far been impressed with performance improvements over Nehalem, especially for memory intensive applications due to the changes in its front-end. However with this sequencing benchmark, I discovered that Sandybridge has taken a major step backward in performance with regard to atomic instructions. Atomic instructions enable read-modify-write actions to be combined into an atomic operation. A good example is incrementing a counter. To complete the increment operation a thread must read the current value, increment it, and then write back the results. In a multi-threaded environment these distinct operations could interleave with other threads doing the same with corrupt results as a consequence. The normal way to avoid this interleaving is to take out a lock for mutual exclusion while performing the steps. Locks are very expensive and often require kernel arbitration between threads. Modern CPUs provide a number of at ## Compare-And-Set in Memcache DevFeed: [Compare-And-Set in Memcache]() Original publisher: [Read original article]() Author: Guido van Rossum (noreply@blogger.com) Published: 2011-08-25T16:59:00Z Content type: tutorial Language: en Sources: [Guido van Rossum]() Topics: [content addressed store](), [Python](), [bug](), [Code]() Tags: [algorithms](), [appengine](), [cas](), [code](), [compare](), [google](), [memcache](), [new-feature](), [python](), [race-condition]() ### AI overview This tutorial explains Compare-And-Set in memcache, including its atomic update use case and how it prevents lost updates caused by race conditions when concurrent requests modify the same key. ### Source excerpt With the most recent release (1.5.3, last week) App Engine's Python API for Memcache has added a new feature, Compare-And-Set. This feature (with a different API) was already available in Java; it has also been available in the non-App-Engine pure-Python memcache client. In fact, I designed the App Engine Python API for this feature to be compatible with the latter, since most of the rest of the App Engine Python API also strives to be at least a superset of that package. But what is it? There seems to be little information on how to use Compare-And-Set with memcache. It is also sometimes (incorrectly) referred to as Compare-And-Swap -- incorrect, because the cas() operation does not actually "swap" anything. The first response when we closed the bug requesting this feature was "Some examples of usage are appreciated." So here goes. The basic use case for Compare-And-Set is when multiple requests that are being handled concurrently need to update the same memcache key in an atomic fashion. Let's assume you are managing a counter in memcache. (Actually, you could use the incr() and decr() operations to update 64-bit integer counters atomically, but just for argument's sake assume you cannot use those -- there are other data types for which the memcache service does not have built-in support.) The naive code to update a counter would be something like this: def init_counter(key): . memcache.set(key, 0) def bump_counter(key): . counter = memcache.get(key) . assert counter is not None, 'Uninitialized counter' . memcache.set(key, counter+1) (Aside: I don't want to have to think about how to get blogger to properly format Python code. I really don't. So just bear with the dots I use for indentation. Okay? Comments pointing me to solutions will be DELETED.) (Aside 2: The assert is kind of naive; in practice you'll have to somehow deal with counter initialization. You also should implement a backup for your counter using the App Engine datastore, so that it can survive evic