The benchmark doesn't accurately represent the real-world database performance because the dataset is too small (roughly half a gigabyte based on [1]?), meaning it fits into the page cache bypassing disk I/O.
I made a local change so that all Put benchmarks ran O(n) O(1) sized transactions and the results were quite different: Void was the slowest, followed by LMDB, Bold, LevelDB, then Badger.
I'd also wager the LMDB author would also (lovingly!) tell us we're holding it wrong
Go doesn't use the C calling convention, but has its own growable stack system and goroutine scheduler that maps to goroutines to threads. So a goroutine can't just call a C function directly.
In order to interface with C code safely, Go's runtime has to jump to the system stack and do some additional setup, make the call, and then switch back. (Adding to that, if the call takes too long, this prevents other goroutines on the same OS thread from running, so the scheduler must jump in and move those goroutines to a different thread.)
All of this is expensive, though we are talking about nanoseconds, not milliseconds. Performance is mostly a problem when doing lots of very quick calls (e.g. you're writing a game engine interacting with something like OpenGL) or lots of slow calls (causing scheduler trashing).
No, my understanding is that Rust uses normal stacks, and it uses a classic threading model, so aside from async, calling C doesn't need to any runtime stuff.
prost is the most widely used Protobuf implementation in Rust, maintained by the Tokio organization. prost generates structs and serialization/deserialization code for you.
easyproto according to GitHib Search is used only by two projects. easyproto provides primitives for serializing and deserializing Protobuf, and requires hand writing code to do both.
A fair comparison would be prost vs google.golang.org/protobuf, or easyproto vs parts of quick-protobuf.
In most cases you can make Go as fast as Rust, but from my experience writing performance-sensitive code in Go requires significantly larger time investment and overall requires deeper language expertise. Pebble (RocksDB replacement in Go by CockroachDB) is a good example of this, the codebase is littered with hand-inlined[1] functions, hand-unrolled loops and it's not[2] even using Go memory management for performance critical parts, it's using the C memory allocator and manual memory management.
> After discovering Chrome are eating my old Mac's battery, I turned to using Edge
What? Have they tried using Safari instead of a Chromium based browser? From my experience Safari is by far the best browser on Mac in terms of the energy efficiency.
I think that argument falls down in the face of the PWA mess in Europe. Standards-based application platforms, to Apple, are at best, a means to an end. And they'll throw them out the second they perceive them in competition with native apps. It's the same recipe followed by MS in the 90's.
Run by the same management. I think an argument of the form "OK, they're trying to kill browser apps on iOS but clearly they love standards and would never do that on a Mac" is unpersuasive.
People have been making dire predictions that macOS will get locked down like iOS since the days when it was called iPhone OS. Not a single step down that slippery slope has ever occurred.
But hey, keep preaching doom, if it entertains you. Just don't expect other people to take you seriously, given the track record.
If on Monday of last week someone had predicted Apple would kill off web apps on iOS, you'd have surely given exactly the same response. And so on Saturday, now they they have, I find that unpersuasive. Make that of it what you will. One person's "preaching doom" is another's "reasoning from evidence".
I switched from FF to Safari to try it out a few weeks ago and the fact I can't click Command+D when I'm on a page I've bookmarked, to remove the bookmark, is killing me.
Aside from testing multiple browsers, that'd make me think you want Chrome or Firefox primarily, if any difference at all they probably have best/most tooling?
All of the Chrome-clones (Edge, Vivaldi, Opera, Arc, etc) have identical dev tooling and extension support because they’re all just Chrome with mostly-surface-level tweaks applied.
The polite thing to do if you have a feature you think would make a FOSS project better is to submit a feature request first. If the maintainers decide they won’t support your feature quickly enough or at all, then fork it. GP did the right thing here
The performance is not that great, but you can already play Cyberpunk 2077
on a M2 Pro laptop using Game Porting Toolkit https://www.youtube.com/watch?v=sPJpkRmsceU
Keep in mind, it has to do x64 -> ARM64 transition and translate Direct X into Metal. I would expect a native version to work better.
Pretty cool but that isn't enjoyable. Those are minimum graphics settings with heavy upscaling and it still barely manages 40FPS with extreme lag spikes in combat (and slowdowns?).
Also having played the game, I can tell you the scenes chosen there (pretty much all of Act 1) are some of the best optimized/least demanding areas. Especially the DLC is going to be unplayable with that performance.
Certainly looks like with just a bit more hardware power and development it could be getting somewhere though.
Great article. If someone is looking for a more advanced example, some time ago, as an exercise, I created an interpreter for a Python-like language in Python https://github.com/akrylysov/abrvalg
[1]: https://github.com/voidDB/voidDB/blob/master/test/bench_test...
reply