I know RPCS3 saw a lot of benefits from avx512, doubt it was to the point of running quicker than the original - but I could see dedicated silicon being the reason negative overhead emulation exists.
But just imagine how much the r36s would be worth in 2001.
that being said that's mostly because of different markets though, it'd be better to compare the switch to the GBA (Nintendo wants maximum money) vs the Chinese government trying to home grow a chip fab (government subsidiaries and a desperate need for good PR)
Oh gosh no it certainly doesn't - while that would be absolutely halarious, part of the overhead is usually making the GBA games play well with something like the Linux scheduler.
Some games back then do crazy stuff like use the number of CPU instructions executed as a timer, so for a playable experience this has to be pretty controlled.
That being said, most emulators allow a time multiplier for their virtual console, so you usually can experience it as fast as your hardware can run (Imagine hooking up a water cooled modern CPU to a minimalist realtime linux kernel and seeing how fast that bad boy can wheel).
Well yeah, I can't say I pulled out my hardware for a benchmark - but I think its a reasonable indicator of a minimum bounds when comparing older hardware with low clocks to newer. ie presumably the GBA doesn't have AVX, but if you're running gameboy games thats just wasted silicon.
Between the GBA to the RK3326 there's almost 2 decades of improvement, honestly 'only' 1000-4000x improvement is actually kinda disappointing considering the previous decades following Moores law.
The RK3326's CPU in it is around 100x faster than the GBA SOC, as well as 64 bit and has 4 cores - so at their respective peaks can be around 1000x faster than a game boy.
The R36S has 1GB of ram, or around 4000x what the GBA had.
So long story short you're minimum 100x overkill for playing gameboy games (assuming an insane 10x overhead)
Unless you're running a virtual GPU (and changing it often enough to remain anonymous), tracking pixels are pretty difficult to obfuscate (the exact thermal environment your PC is in will even effect timing).
And thanks to big tech this state of the art tracking is on essentially every website.
Clearing site data/private mode is a way to ask nicely that websites don't track you, but user intention hasn't been respected for around 3 decades by now.
Biggest factor I can think of is your recovery strategy, if downtime is OK data and simplicity is key I'd honestly take option 1 and copy the files and directories directly to the new drive (with xfs or something on it).
Dd'ing anything else a la option 2 and 3 (LUKS container/LVM LV) will increase the size of your backups, because all empty blocks will be copied exactly as they are (even more so in the encrypted version as they become almost uncompressible).
That being said, its possible to "qemu-img convert" the entire 16TB LVM LV into a Qcow2 file, so you could later clone/attach it if a disked failed with the added benefit of qcow compressing those annoying zeros (but still doesn't beat the space efficiency of just copying the files cause non-zero but empty blocks probably exist).
I'd avoid option 4 and dd'ing the LVM physical volumes, because it can get a bit annoying dealing with duplicate PV UUID's. I could only seeing this being a choice if you are handling consistency somehow and want to be able to replace SSD's without much down time.
All that being said damn I'm jelly, you have as much storage in 5 drives as I do in like 20.
That's pretty cool, so like DMA but because the hardware couldn't (directly) tell the difference instead of an actual standard
For what it's worth it still makes me feel safer as a trans person seeing stuff like this, among the majorly hateful news of today.
That's really cool.
I wonder if the design is open, its out of my price range but it looks like it'd be pretty fun to build.
The 200s were quite a long time ago
I know RPCS3 saw a lot of benefits from avx512, doubt it was to the point of running quicker than the original - but I could see dedicated silicon being the reason negative overhead emulation exists.
What's MMU mean in this context again?
But just imagine how much the r36s would be worth in 2001.
that being said that's mostly because of different markets though, it'd be better to compare the switch to the GBA (Nintendo wants maximum money) vs the Chinese government trying to home grow a chip fab (government subsidiaries and a desperate need for good PR)
Oh gosh no it certainly doesn't - while that would be absolutely halarious, part of the overhead is usually making the GBA games play well with something like the Linux scheduler.
Some games back then do crazy stuff like use the number of CPU instructions executed as a timer, so for a playable experience this has to be pretty controlled.
That being said, most emulators allow a time multiplier for their virtual console, so you usually can experience it as fast as your hardware can run (Imagine hooking up a water cooled modern CPU to a minimalist realtime linux kernel and seeing how fast that bad boy can wheel).
Well yeah, I can't say I pulled out my hardware for a benchmark - but I think its a reasonable indicator of a minimum bounds when comparing older hardware with low clocks to newer. ie presumably the GBA doesn't have AVX, but if you're running gameboy games thats just wasted silicon.
Between the GBA to the RK3326 there's almost 2 decades of improvement, honestly 'only' 1000-4000x improvement is actually kinda disappointing considering the previous decades following Moores law.
Just did a google search, here's the GBA and here's the RK3326 (which is the SOC in that handheld).
More like a PCie storage device with DMA no?
Sorry if that's pedantic lmao, but I feel like even the GBA ram blew nonvolatile storage out of the water
The RK3326's CPU in it is around 100x faster than the GBA SOC, as well as 64 bit and has 4 cores - so at their respective peaks can be around 1000x faster than a game boy.
The R36S has 1GB of ram, or around 4000x what the GBA had.
So long story short you're minimum 100x overkill for playing gameboy games (assuming an insane 10x overhead)
Damn, be careful you don't impregnate yourself with all that hardware
Cause LLMs can't yet be nepo babies
Unless you're running a virtual GPU (and changing it often enough to remain anonymous), tracking pixels are pretty difficult to obfuscate (the exact thermal environment your PC is in will even effect timing).
And thanks to big tech this state of the art tracking is on essentially every website.
Clearing site data/private mode is a way to ask nicely that websites don't track you, but user intention hasn't been respected for around 3 decades by now.
With the same IP, CPU, GPU, and networkcard??
Easily fingerprintable
Sounds good to me, let's make America pay for 11/12th of the cleanup and Canada can cover the last 1/12 as per their emission ratios
Biggest factor I can think of is your recovery strategy, if downtime is OK data and simplicity is key I'd honestly take option 1 and copy the files and directories directly to the new drive (with xfs or something on it).
Dd'ing anything else a la option 2 and 3 (LUKS container/LVM LV) will increase the size of your backups, because all empty blocks will be copied exactly as they are (even more so in the encrypted version as they become almost uncompressible).
That being said, its possible to "qemu-img convert" the entire 16TB LVM LV into a Qcow2 file, so you could later clone/attach it if a disked failed with the added benefit of qcow compressing those annoying zeros (but still doesn't beat the space efficiency of just copying the files cause non-zero but empty blocks probably exist).
I'd avoid option 4 and dd'ing the LVM physical volumes, because it can get a bit annoying dealing with duplicate PV UUID's. I could only seeing this being a choice if you are handling consistency somehow and want to be able to replace SSD's without much down time.
All that being said damn I'm jelly, you have as much storage in 5 drives as I do in like 20.
Whoops, yeah should have probably put a link in the main thing,
here's a fourm post describing how to
Theres a hidden option to make it multi core, which (on a machine like a threadripper) can insanely speed up the process.
edit: here's a fourm post describing how to