Isn't the CEO taking themselves out of the equation in this demo?
13,796 karma · joined February 28, 2014
there is one already, and you would know if you weren't a new account complaining about "What happened to this site" after a comment from a 20yo account.
all local live state. The idea is that most objects are ephemeral and will be orphaned before there is a need to be collected.
Everything mostly worked out of the box.
Ages ago in C++98/03 era, cons based lists were the only way to do type lists or tuples, so solutions like these did see some production use (and yes, it did kill compile time).
Of course these days variadics have made these solutions obsolete.
Well, most architectures do not use plain jumps with implicit arguments for function calls, but have explicit call/ret or branch-with-link instructions. Even those that used jumps had branch hints. The reason is that the microarchitecture must know about call/ret pairs to be able to predict the return path as the generic dynamic predictor is just not good enough for such a common path.
Reduced prediction performance compared normal calls is actually a concern for some coroutine and async code.
> in C we don’t have any dynamic lookup inside functions—every dynamic jump comes from an explicit conditional statement
function pointers.
A small comment after a cursory look: the signaling in CoroTracer.h:162 is susceptible of missed wakeups; you would need a #StoreLoad fence between the slot .seq store and the sleeping flag load (and for the load to be an acquire). The traces probably needs a mirror change.
As the load is relaxed, I assume you are not worried by missed wakeups and it is ok if the tracer is woken up by a latter trace. Of course there might not be a latter trace and you would need a timeout on the sleep.
Airstrip one is disappointed.
More than taking control of Iranian petrol, this is probably more an attempt at cutting off China access to it (and also generally eliminating one of their allies), same as for the Venezuelan invasion.
A specific microarchitecture might alleviate this a bit with lower latency cross-core communication, but the solution (using a single naive RW lock to protect the cache) is inherently non-scalable.
Is it bypassable by a sufficiently determined child? Yes, but so it is the current age verification nonsense.
If I understand the problem correctly, the standard library could specialize the scoped lock objects for the shared mutex, online allocate the waiter object in the lock (so it will be in the stack) and use an internal dedicated API.
It might be harder (but not impossible) to interoperate threads using direct lock calls with threads using the scoped API.
In any case it is a moot point, as I don't think any std library does it nor will never do as it would probably be ABI breaking.
This needs updating:
> In the past, most cars had an anti-theft feature that restricted the turning of the steering wheel if the key was not inserted in the ignition. These days, for convenience, is enough that the key has been in the vicinity of the car in the recent past.
Early on personally I had doubts they could scale their CPU to high end desktop performance, but obviously it hasn't been an issue.
My nitpick was purely about using clock per cycle as a performance metric, which is as much nonsense as comparing GHz: AFAIK Apple cpus still top at 4.5 GHz, while the AMD/Intel reach 6Ghz, so obviously the architectures are optimized for different target frequencies (which makes sense: the power costs of a high GHz design are astronomical).
And as an microarchitecture nerd I'm definitely interested in how they can implement such a wide architecture, but wide-ness per-se is not a target.