I'd take the cash. I walk past a half dozen cash machines on any given workday where I can deposit the cash in to my bank account and it'll clear and be ready to spend instantaneously.
On the other hand, it's trivially true that the store which "issues" (caveat explained in the article, they don't actually issue anything themselves) a gift card will accept it as a valid form of payment.
It sounds like the way the parent front is phrased fits that. If they're only willing to pay in gift cards, that's a requirement, so it's likely a scam. If they're also willing to pay in cash, then you can probably just take the cash and be fine?
> The 21st century is now 25 years old. Measured since the start of 2000, stock returns have been lower than over the 20th century, though global equity investors still enjoyed an annualized real return of 3.5% and an equity risk premium relative to bills of 4.3%
Optimising hardware to run existing software is how you sell your hardware.
The amount of performance you can extract from a modern CPU if you really start optimising cache access patterns is astounding
High performance networking is another area like this. High performance NICs still go to great lengths to provide a BSD socket experience to devs. You can still get 80-90% of the performance advantages of kernel bypass without abandoning that model.
Not only that, but you can also always form a normal (ptr, size) slice reference to any piece of the ring buffer, even when it wraps. This is really helpful for Eigen arrays that you need to rotate.
I guess one aspect of it is that in really high performance fields where you're taking in lots of stringy real inputs (FIX messages coming from trading venues for example, containing prices and quantities) you would simply parse directly to a fixed point decimal format, and only accept fixed (not scientific) notation inputs. Except for trailing or leading zeros there is no normalisation to be done.
Parsing a decimal ASCII string to a decimal value already optimizes well, because you can scale each digit by it's power of 10 in parallel and just add up the result.
I don't understand why they wouldn't give a pre-release patch to the bug reporter (especially if it's someone like Google) for them to analyse before doing a final release.
If they were actively working with Project Zero instead of being seemingly silent, this wouldn't happen
This is where FOSS is still winning and will always win. Fixed happen in the open and bad fixes can be called out
I’m not sure why you think it’s the researchers responsibility to verify patches. It would be nice, especially if they’re knowledgeable in the code, but Microsoft have the resources to put someone else in that position too.
That’s different. I’m not here to mark your work but if you publish your work, I’m happy to publicly point out that you’re wrong, especially if you’re Microsoft size and should have work checkers internally and are continually doing the wrong think and putting people at risk as a result.
Generally I find it's best to implement push operations as try_push operations and let the caller decide if they want to drop, or spin.
There are definitely designs that can deal with non-POD data of variable size, although that does imply heterogeneous types, which will need some sort of type erasure to destroy safely.
A good write up, but a preallocated MPMC queue can be built without using CAS on every push and without fixed size slots and without multiple rings.
While even SPSC ring buffers are simple they are not particularly efficient in the case where the consumer is keeping up with the producer (the ideal case for a queue) due to all the cacheline ping pong. They are not the lowest latency solution
Martin Thompson, of LMAX Disruptor fame, has I believe a novel solution in Aeron called the logbuffer, which fully formed 10+ years ago in that codebase.
