1,688 karma · joined June 6, 2017
I did see your issue immediately, though, and I could remember having the same issue with my own code. I remember assigning Shaders into a shader manager. They were already dead.
These days I prefer to in-place construct most things, unless there's a particular reason for assignment.
I have a C++ game client, a C++ game server, and a shared C++ game script that is transferred to all clients, running in a RISC-V emulator. That means the script will fundamentally execute the same way on all clients, and the server. I have no idea what everyone else is doing. This is what I'm doing now, and the more fleshed out it's becoming, the more I actually like it this way. I don't think I could easily "go back" to other solutions.
I don't like that protobuf has recently started linking with abseil, which despite being a good framework, I can't use it if it doesn't build absolutely everywhere I need it to. So, maybe I'll be forced over to CapnProto one of these days?
HN is one of the few web-pages that get straight to the point, and could not be any more well designed.
Meanwhile, the Windows XP codebase had 45M LOC in 2011.
Truly big codebases need to be written in sane languages, mostly OOP ones. That excludes C, Zig and Rust.
For me SO is still very important. It has people like Peter Cordes that answer my complicated questions about the inner workings of modern CPUs, inline assembly and other esoterica. You can also find Mark Adler answering questions about CRC computations, polynomials and so on!
Eg. https://stackoverflow.com/questions/69830626/unable-to-get-t...
Copilot lets me get started, even if it's wrong sometimes. There have been times where I have been surprised by how it took something I wrote for a server, and presented the correct client-side implementation.
I've used it a few times to describe a problem and let it handle the solution. It's not very good, but I wonder if one should place more blame on PEBCAK and put more time into problem-description. I gave it a few more paragraphs to describe the problem, and eventually I could take it from there. It was still wrong, but enough to get me started. Immensely helpful that way.
Another aspect that I'm wondering about is if it will be able to do more with better documented code. Anyone have experience with that? I've started to write more doxygen comments, and hoping to see if there's a slow shift to more accurate predictions.
As far as WASM going away: Sadly, I think browsers are just going to make up a larger and larger share of what computers do.
"Because Rust" and safety, of course. I wonder if programming on Windows just sucks in general, and all these are Windows trading shops. Do you even have all the tools you need to write large programs on Windows? Valgrind, libfuzzer, etc. etc.
I couldn't find any information about work-arounds.
I do see one minor nitpick though. The inlined host call needs to also use an "m" operand, otherwise the compiler could optimize out the actual data (making it a dead-store).
asm volatile("scall" : "+r"(a0) : "r"(a1), "r"(a7));
to asm volatile("scall" : "+r"(a0) : "r"(a1), "m"(*a1), "r"(a7));
Usually, we want to cast a1 here to a fixed or variable-length array in order to inform the compiler of the size of the data, but here the size is known. I believe it's enough with a deref. If not, cast it like so: *(uintptr_t(*)[13]) a1It's cool that you can inline sandboxed functions like that. I'm curious about how you arbitrarily select and call functions though? A string-lookup kind of thing?
I agree that it could as well have been MIPS or ARM.
Interpreted libriscv vs LuaJIT: https://gist.github.com/fwsGonzo/1af5b2a9b4f38c1f3d3074d78ac...
libriscv vs. Luau: https://gist.github.com/fwsGonzo/5ac8f4d8ca84e97b0c527aec76a...
wasmtime: https://medium.com/@fwsgonzo/using-c-as-a-scripting-language...
You're probably right that things can be improved. But my implementation has the aforementioned latencies right now.
For the benchmarks I did my best writing good Lua, but I am not a pro. Call overhead is also subtracted out of every benchmark after call overhead is measured. So that extra overhead is a permanent feature of these implementations. I also noticed that most of my script functions have at least ~3-4 arguments, which seems like it would be quite costly. Just look at the 8x arg benchmark and divide by 2, I guess. Another 100ns right there. Baseline 150ns on a micro benchmark is going to become at least a microsecond in prod when everything is random and semi-cold.