vvanders

It's also blazing-fast.

I've done some benchmarking on JSON -> in-memory borrow structs and it was pretty darn impressive while being fairly ergonomic to use compared to a streaming parser.

As someone who started pretty high up the stack(Visual Basic!) and kept peeling layers away out of curiosity I will say working with a CPLD/FPGA was really eye-opening. Latency difference between SRAM/DRAM and the "why" in pipelining made a bunch of disjointed approaches to optimization just drop into place.

I'd largely agree, there's a reason 3PH(and SSQA) are ubiquitous. If you support that standard it opens up a massive market of compatible attachments.

Yeah, I think in game dev there was also a culture of understanding that leaking that stuff just hurt whoever was working directly on it.

Back when I was in industry we all knew what everyone else was working on including big IPs and next gen console stuff. That might have also been a factor of how small and tight nit of an industry it was.

Anything that mentions Industry 4.0 and 5G together leaves me with a large degree of skepticism.

Yep, what's wild to me is there's actually a non-insignifiant overlap between radio and networks(ex: aloha from RF links in Hawaii ended up heavily influencing Ethernet and most of your cable modems use a variation of coding scheme(QAM) that is also widely used in more modern radio protocols).

Except that digital depends on... analog radio. I honestly wish there was better ecosystem for SSB 2M or robust SDR platforms. You have a host of digital modes on HF but most of the 2M/70CM radios/chips are FM/FSK.

Or sometimes you have an approach that is high risk/reward. That's totally fine to take as long as your aware of the risk and have mitigations or offramps at the right points if you find the path isn't viable.

Yup, there's also a big problem with gatekeeping and what's "true" ham radio.

I wish it was different since you can do things with ham radio that are not possible without a license but then I look at the state of something like APRS that is still stuck in the '80s and it's depressing. The M17 project may change that and FT8 is starting to make inroads but I feel like the attitude you mention above keeps out people who would be taking it to new places and domains.

Yup, pretty much. When I left industry it was almost a 100% salary bump. I tossed 2 months of PTO(because the company wouldn't pay it out, per state law and I could never take it) and I made up the difference in the first few paychecks.

Tons of fun problems and passionate people but the industry is an absolute meat grinder. Last I looked at the statistics median industry career length was ~3 years.

Stock, I the game industry? That's a riot.

In my time in that industry the only bonus/non-salary compensation I ever saw was a $20 Starbucks gift card for pulling a 90hr week before a major demo deadline.

Pedantically, none of them are C++ either.

The better comparison would be the 16" MBP and those look to be within about 1lb of each other. If your not going to be using the GPU heavily then you can just use a standard usb-c charger with should be similar in size to the MBP.

If you like this stuff data oriented design[1] is a nice framework that isn't arch specific(but can be extended to be if you need to make more gains that are arch aware). Back when I worked in the PS3/X360 days engines written for PS3 had better cache locality(SPUs forced hard limits vs hitting a cache miss) and ran faster on the X360 as result well when ported.

You can do do fun things like using radix sort with bucket sizes that line up well with L2/L3 caches(saw a multi order of magnitude speedup for that one) and data aware layouts that net 10-30x speedups for the same data. Many RMDBs use similar approaches from what I understand as well.

[1] https://en.m.wikipedia.org/wiki/Data-oriented_design

Even "gaming" laptops have come a decent ways in size/form factor. I picked up a Zephyrus G15 a bit ago and it's pretty portable while having the ability to sink a good amount of wattage.

Their EMMC issue on the S was pretty egregious, that's something you get right in even basic consumer electronics. They also had numerous issues with door handles(I had two fail once the car was outside of warranty).

There's things they do well but I don't know if I'd qualify them as having better reliability.

There's an incentive for chip vendors to not standardize since it makes migration hard and drives vendor lock-in. The CPU cores are one part but equally important is the peripherals and external featuresets.

The Ars review was fairly positive as well.

https://arstechnica.com/cars/2021/09/rivians-67-500-314-mile...

No rain in space makes satellite a bit more viable, they don't mention throughput but I don't see how you get around the issue of atmospheric interference.

Pretty sure LTO already provides that functionality(I wish Rust had LTO on by default but it's fairly straightforward to flip on).

Oh totally.

Half of games networking is finding out what you can "get away with" from an impact/user perception. Ex: play hit effects, sounds in a de-synched way locally but have major game events be authoritatively acked by the server, the local events also do a good job of masking the latency. The other half is really cool tricks like dead-reckoning or lock-step[1] which uses a completely deterministic game state to sync hundreds of entities over latent connections.

It's a really fun design space that's leverages heavily both the game design(designs where players "predict" are easier to keep in sync/fun), a level of deception to hide latency and cool technical approaches to hard problems in a non-deterministic environment.

[1] https://en.wikipedia.org/wiki/Lockstep_protocol

> and maybe more surprisingly, add/removing virtual functions

I don't have the spec handy but fairly certain that v-table implementation is compiler specific and while it may work it isn't guaranteed. However if you declare the function symbols as dynamic then you can leverage the linker to dynamically resolve the right symbols with the matching opaque data and achieve binary compatibility(assuming you use the same compiler or a compatible compiler ABI and all other caveats around C++ binary compatibility).

I think you may be indexing a bit into your exposure and painting the industry in a broad brush.

I've seen impressive things done with Lua, from literate AI programming with coroutines to building compostable component based language constructs instead of standard OOP. You have things like GOAL[1] which ran on crazy small systems (the Lua I saw ran in a 400kb block as well).

On performance, data oriented design and efficient use of caches is the way you get faster. I've done it in Java, I've done it in C#, I've done it in Rust and C++. Certain languages have better primitives for data layout and so you see gamedev index into them. We used to do things like "in-place seek-free" loading where an object was directly serialized to disk and pointers were written as offsets that were fixed up post load. Techniques like this easily net 10-30x performance benefits. It's the same reason database engines run circles around standard language constructs.

[1] https://en.m.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Hierarchical component based designs have been around in game-dev for ages. I first used them in '05 but I remember prior art even before then. It was pretty common to have a declarative way to define components(usually through a scripting language like Lua or sometimes custom DSL).

I agree on the performance aspect, any inner-loop stuff always was down in a native language or heavily JIT'd path, but even then data layout drove it even more which usually required structuring the upstream systems ahead of the core logic. It's the reason why there's no "one-size fits all" game engine. They all make very discrete trade-offs in terms of entity counts, open world vs constrained layout and the like.

Yeah, I can totally see the argument that it's a programming model that's well understood and you can get a productivity boost from that. However I don't think you can say that doesn't come with a cost, otherwise it would have been pretty widely adopted across the industry.

The "No. There is no additional overhead. Components participate in a unified renderloop outside of React. It outperforms Threejs in scale due to Reacts scheduling abilities." made me do a serious double-take.

If you want to go fast in this space then you need to care about data layout and how the system is structured end-to-end. Calling a function per object is going to hit a wall regardless of how you schedule.

Hundreds/Thousands of updates is not small but it's also not massively impressive either. I've done ~2,800 node scene graphs on underpowered ARM chips back in '09 at 60FPS including rendering. You have to use NEON, and be aware of your caches. No scheduling magic is going to change that unless you're just deferring work which sounds like what may be happening there.

FWIW I've also done this in Java via FlatBuffers(which uses ByteBuffer internally) to keep data coherency when driving animations frames so it doesn't require dropping down to C/C++/Rust(although C#'s value types do make it easier).

Showstopper![1] covers Windows NT in a similar vein and Dealers of Lightning[2] is another good read that goes into some if the really interesting history of Xerox PARC.

[1] https://www.amazon.com/Showstopper-Breakneck-Windows-Generat...

[2] https://www.amazon.com/Dealers-Lightning-Xerox-PARC-Computer...

https://www.theroot.com/as-haiti-burns-never-forget-white-pe... covers it in some more detail.

Like the article says it sounds unreal and almost to suspend disbelief, however if you independently look up the major events outlined they pencil out.

Everyone basically did Lua back in that era since it was so damn small. I had it running on 400kb of memory on the PSP, used it for multiple UI frameworks around that era on mobile hardware.

Someone still hasn't built an equivalent to LuaJIT. Quickjs is in the same spirit but still interpreted, the way LuaJIT does C FFI is just pure awesome[1].

[1] https://luajit.org/ext_ffi_tutorial.html

Yeah, it's highly workload dependent. I've used restrict in anger to accelerate particle systems and we saw a significant speed boost.

Even a 5% speed increase is nothing to discount give that it's "free" once they have LLVM handling it correctly. I agree with the conclusion that if you have to manage the aliasing manually it's very limited in scenarios where you would want to deploy that given the failure modes of getting it wrong.