Why not just make all the abandon transactions into fake discarded transactions, discard them at the send later. E.g. by poisoning the frame checksum or setting something invalid on them, so they get discarded.
Seems you'd be doing this anyway with the dummy transactions.
Then you have no branch, though may want to add dummy transactions anyway to keep the code in cache.
The article suggests flooding the system with dummy "should send" transactions so that they become the majority.
Quote:
> One such solution that I know of is one that Carl Cook talked about during his CppCon 17 talk2: we can fill our system with mocked transaction data for which should_send(t) returns true. We have to do this enough times such that the mocked transaction data becomes the vast majority over the real data, so the branch predictor will be primed to assume that the send() path will be executed practically on every resolve() call. Overall, this may actually be a better approach than hard-coding prediction rules, because those rules wouldn’t really guarantee us that the whole send() path would get executed (the assumption may just lead to partial execution, until the should_send(t) condition is actually evaluated and the pipeline is flushed; so at the end we may still have important stuff not placed in the instruction/data cache).
What I am suggesting is to remove the branch entirely, and instead poison the "should abandon" transactions so they get dropped or null routed on the NIC. This is the kind of thing that low latency cut through L1 switches do.
Thereby removing the CPU branch predictor from the equation entirely.
> The only victim of the accident was Wim Delaere, a computer science student reported to have been either 18 or 19 years old.[4][5][1] He was sleeping alone after celebrating the end of his university exams the previous day when the MiG crashed and killed him at 10:30 am. His mother and brother were shopping for groceries in Kortrijk, and his father was working in Ypres.[4]
From the linked Wikipedia article on one of the answers.
I can't find anything that would suggest this is true, but I would love if you were able to link me something proving me wrong, as I loved that movie growing up and like reading about it still.
This sounds really annoying.
I prefer claudes opt in implementation, where if you want to reference an earlier chat you can just say, remember we spoke about xyz and otherwise the feature seems to be completely off.
Yes though only 15 minutes a day max at regular break points in the day. Breakfast, lunch usually.
I have one of those parental limit things set for it from 5 years ago. I used to run into the 15 minute limit every day but now I rarely see it pop up.
We have Yoto for our kids and I was initially skeptical (the cards are quite expensive) but actually it's been amazing. Probably the biggest benefit that we didn't even know is that they have a sort of radio/podcast thing for kids called Yoto Daily that's really well produced and totally free.
This is actually pretty amazing, definitely the most impressive pwa I've ever seen.
It took me about 3 minutes to add to my home screen, export a opml from pocket casts and import it to whatever.
Having offline downloads, ability to adjust playback speed etc is really cool too.
Nice work!
I'm on my phone now, so I'm curious to see how it looks on a browser. Obviously syncing of podcasts / listening positions is not going to work, by design?
The AI search is actually kind of cool for discovering podcasts too, I kind of rolled my eyes a bit when I read it, but it actually worked ok for a query I tried, and I do find it difficult to find new podcasts.
> Obviously syncing of podcasts / listening positions is not going to work, by design?
Not sure, can you say more? Quick potential answers in the meantime.
For syncing, there's an auto-sync that runs in the background and prioritizes the shows that you've listened to most in the past month, but eventually cycles through all podcasts that you follow. There's also a manual sync on the Following page.
For listening positions, there's a Queue where you can drag individual episodes up and down to change the order, and playback will automatically cycle to the next episode in the queue when the playing episode finishes.
Ah, just realized you might be talking about syncing state between devices. Definitely haven't tackled that, as there's no coordinating server in the architecture at this point. But I did recently add "beaming", which lets you quickly transfer your subscription lists between devices with a QR code backed by an ephemeral, signed link.
I believe most of those POS systems can operate in offline mode, in Europe at least. I have friends who work for large event organizers, and they have spoken about how if the system is offline the bars can continue to take payments, but there is a risk as a person's account may not have sufficient balance to make the charge when the system comes back online.
Most people here pay by card and I would say the vast majority use debit cards. A lot of people don't even have credit cards, unlike the US.
I'm no expert so may be wrong about some of this, and maybe huge events like these have these systems in place due to the risk of having to shut down bars etc. Many events are completely cash less these days.
> I believe most of those POS systems can operate in offline mode, in Europe at least.
I was able to pay "offline" for my groceries at corner store nearby when their terminal had really bad or no connection at all - and that did happen a lot. They were just gathering all payments and when the "computer guy" was around he'd upload these to the Internet. The only caveat was that for some reasons these payments would be stuck for more than a week on transactions list
reply