That's not true at all. I wrote a simple set of threading functions and had 0 deadlocks no matter what I do to it. On youtube I watched a guy write out every possible state of his data structure for hashmap. It's implemented using atomics. It preformed pretty well according to the person and it also did not deadlock after being used in production for years
I saw once a guy suggested to contact stripe for an account manager. I don't think he was very specific and I'm not sure if you can simply create a ticket or email them but I think that is a good step
All the object allocation, pointer chasing, and general indirection is what makes JSON parsing slow, particularly building up tree structures. Bump allocators and the like don't help much, at least for the parsing--most malloc implementations already do fast, O(1) allocation for small objects, and have for decades. (Arenas are useful for making deallocation O(1), though.)
If you care about raw JSON throughput, use Ragel or something similar to build a state machine that directly parses JSON into a flat, native data structure. Now you have zero allocations without even needing to shim malloc/free. AVX-512 would still be at least as useful, but it's a much more difficult problem to leverage SIMD in a parser generator than in a simple string escape routine or behind a more abstract interface like a regex library.
Quite a few language environments these days provide in-language JSON deserializers, but they're still significantly slower than they could be even when they deserialize to flat data structures. The macro languages and internal compiler intrinsics used to accomplish this are the worst possible environments for development. Lisp-like languages aren't really an exception as they tend to trade easier in-language transforms for a steeper climb when it comes to generating optimized native code for the transform.
It's not about the format per se, but more about the fact that you're parsing an unknown/fully general structure in that format. APIs like Rust's serde can help to avoid excessive allocation when you have JSON in a known schema.
This claims 3gb/s, saturating nvme full queued read. It’s not clear if they construct data or just parse it, but you have to construct data with any format. Other libs also do a great job. Also, io latency shoud be accounted for, because average jsons usually fit into one sdd block, afaiu.
Yep. I think the fastest nvme's were a tad above 3gb and network IO is certainly faster. It always irks me when something stop being true 15-20years ago is cited today
The internet is so bad that when I see titles like these I know the article will not be true at all. The great thing is I can see lemire next to the title and I absolutely know not only did he walk the walk but he can write about it in an understandable way. I upvoted before reading and I haven't yet been disappointed. -Edit- Done, it's nice and short and I want to reread the code example. I'm not familiar enough with avx512
Yeah I know, I'm saying only Daniel (and Carmack) can pull of titles like that without people thinking they're not telling the whole truth. I still remember john's tweet "I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that?". A nerd said "Either he's crazy or this is an unusual situation" it was neither Carmack followed it up with https://superuser.com/a/419167
So one person said creating the rust interface is very difficult to do correctly and the other said rust bare metal isn't complete enough for his use case
I called both of these (and compile times) when people first tried to get rust on the linux kernel. Maybe it's better to acknowledge these problems before you start instead of beating your head? I'm no psychic and I know I wasn't the only one who called these
> Maybe it's better to acknowledge these problems before you start instead of beating your head?
What's unacknowledged? They're doing exploratory work. That often involves developing under known and expected limitations to understand the problem space and have something to test with when progress is made towards addressing limitations.
The fact that writing unsafe rust code is harder than unsafe C due to more rules? The fact that Rust has little support of nostdlib which is what the kernel is using? There's also the fact that most of the time in drivers (in my limited experience) you almost always want unsafe things but I assumed noone would think or admit that one
When it comes to common knowledge in programming it's more often incorrect. I still see people telling experts they shouldn't use global variables, that you can't beat the optimizer, that you should use a library (for something as trivial as left pad) etc
Got any concrete examples? I hear this a lot, but have never experienced it. I’ve been using Firefox as my primary desktop browser for years now. I can’t think of any website that didn’t function. But maybe I encountered one and just thought the site was down?
In my case: several financial institutions that I have accounts with and lots of enterprise apps and gear with web UIs either break silently, have certain functions that don't work, or block with an error telling you to use a supported browser. (If they're nice, they even tell you which ones are supported.)
For a while, Slack didn't support all features on Firefox despite the technology being there, I don't know if this is still the case.
More than once I have spent precious time filling out some form or going through some wizard only to find that I cannot “submit” or that validation is failing on some field or other in Firefox. Switching to a Chromium based browser works. I know it has happened to me at my bank. I cannot recall exactly where else. Reservation systems? A couple of travel approval sites I think ( during COVID ).
The Hebrew language Nespresso site pops up a browser dialogue "you have unsaved changes" every time one tries to browse to another page. The dev team is aware of it, but "the site only supports Google Chrome" so they don't fix it.
https://www.nespresso.com/il/he/
The version of Unit 4 that we use at work only works in Chrome.
That said, lately, that particular thing has been the only one that I need to use that outright doesn't work.
I think a number of Google technologies are slower in Firefox on purpose, but I just avoid them and keep telling competition authorities about their abuse of power.
Reading that thread, it sounded like OPs issue was more with an extension blocking something than the browser, but I’ll admit, I do not use GoDaddy, so I haven’t experienced it first hand.
Why do I feel like I'll still be asked to like and subscribe?
I'm not interested in youtube cloning good resources we already have only for it to be sunset or charge a bunch. Like when people got upset about the firebase and map price hike
