Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating away from Rust

deadmoney.gg

Post reply on HN
Print view View original

401–410 of 799 posts

Re: Migrating away from Rust

#401

Post by jcalvinowens »

ryao wrote: post #394
uecker wrote: post #390

Earlier quoted context omitted.

A comparator can be inlined just fine in C. See here where the full example is folded to a constant: https://godbolt.org/z/bnsvGjrje Does not work if the compiler can not look into the function, but the same is true in C++.

That does not show the comparator being inlined since everything was folded into a constant, although I suppose it was. Neat. Edit: It sort of works for the bsearch() standard library function: https://godbolt.org/z/3vEYrscof However, it optimized the binary search into a linear search. I wanted to see it implement a binary search, so I tried with a bigger array: https://godbolt.org/z/rjbev3xGM Now it calls bsearch i…

With optimization, it will really inline it with an unknown size array: https://godbolt.org/z/sK3nK34Y4

That's not the most general case, but it's better than I expected.

Re: Migrating away from Rust

#402

Post by bionhoward »

ryanisnan wrote: post #119
mikepurvis wrote: post #37

Earlier quoted context omitted.

The advantages of correctness, memory safety, and a rich type system are worth something, but I expect it's a lot less when you're up against the value of a whole game design ecosystem with tools, assets, modules, examples, documentation, and ChatGPT right there to tell you how it all fits together. Perhaps someday there will be a comparable game engine written in Rust, but it would probably take a major commercial s…

One of the challenges I never quite got over completely, was that I was always fighting rust fundamentals, which tells me I never fully assimilated into thinking like a rustacean. This was more of a me-problem, but I was constantly having to change my strategy to avoid fighting the borrow-checker, manage references, etc. In any case, it was a productivity sink.

Personally, I don’t think of it as fighting, more like “compiler assistance” —

you want to make some change, so you adjust a struct or a function signature, and then your IDE highlights all the places where changes are necessary with red squigglies.

Once you’re done playing whack-a-mole with the red squigglies, and tests pass, you know there’s no weird random crash hiding somewhere

Re: Migrating away from Rust

#403

Post by the__alchemist »

Animats wrote: post #231

Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues.…

Great write-up. I do the array indexing, and get runtime errors by misindexing these more often than I'd like to admit!

I also hear you on the winit/wgpu/egui breaking changes. I appreciate that the ecosystem is evolving, but keeping up is a pain. Especially when making them work together across versions.

Re: Migrating away from Rust

#404

Post by Narishma »

palata wrote: post #255
wffurr wrote: post #237

Earlier quoted context omitted.

>> a bit as if people went for C++ instead of a JVM language "because the JVM is slow" (spoiler: it is not) The OP is doing game development. It’s possible to write a performant game in Java but you end up fighting the garbage collector the whole way and can’t use much library code because it’s just not written for predictable performance.

I didn't mean that the OP should use Java. BTW the OP does not use C++, but Rust. This said, they moved to Unity, which is C#, which is garbage collected, right?

Unity games are C#, the engine itself is C++.

Re: Migrating away from Rust

#405

Post by ryao »

jcalvinowens wrote: post #401
ryao wrote: post #394

Earlier quoted context omitted.

That does not show the comparator being inlined since everything was folded into a constant, although I suppose it was. Neat. Edit: It sort of works for the bsearch() standard library function: https://godbolt.org/z/3vEYrscof However, it optimized the binary search into a linear search. I wanted to see it implement a binary search, so I tried with a bigger array: https://godbolt.org/z/rjbev3xGM Now it calls bsearch i…

With optimization, it will really inline it with an unknown size array: https://godbolt.org/z/sK3nK34Y4 That's not the most general case, but it's better than I expected.

Nice catch. I had goofed by omitting optimization when checking this from an iPad.

That said, this brings me to my original reason for checking this, which is to say that it did not use a cmov instruction to eliminate unnecessary branching from the loop, so it is probably slower than a binary search that does:

https://en.algorithmica.org/hpc/data-structures/binary-searc...

That had been the entire motivation behind this commit to OpenZFS:

https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7a...

It should be possible to adapt this to benchmark both the inlined bsearch() against an implementation designed to encourage the compiler to emit a conditional move to skip a branch to see which is faster:

https://github.com/scandum/binary_search

My guess is the cmov version will win. I assume merits a bug report, although I suspect improving this is a low priority much like my last report in this area:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110001

Re: Migrating away from Rust

#406

Post by klabb3 »

zxvkhkxvdvbdxz wrote: post #364
klabb3 wrote: post #325

Earlier quoted context omitted.

Huh? Usually languages that are ”ignored” turns out to be for reasons such as poor or proprietary tooling. As an ignorant bystander, how are things like Cross compilation, package manager and associated infrastructure, async io (epoll, io_uring etc), platform support, runtime requirements, FFI support, language server, etc. Are a majority of these things available with first party (or best in class) integrated toolin…

F# compiler is cross os and allows cross compilation (dotnet build --runtime xxx), its packaged in most Linux distros as dotnet.

Ok that helps! So where does F# shine? Any particular domains?

Re: Migrating away from Rust

#407

Post by jayd16 »

pcwalton wrote: post #311
_bin_ wrote: post #297

Earlier quoted context omitted.

I saw a good talk, though I don't remember the name, that went over the array-index approach. It correctly pointed out that by then, you're basically recreating your own pointers without any of the guarantees rust, or even C++ smart pointers, provide.

But Unity game objects are the same way: you allocate them when they spawn into the scene, and you deallocate them when they despawn. Accessing them after you destroyed them throws an exception. This is exactly the same as entity IDs! The GC doesn't buy you much, other than memory safety, which you can get in other ways (e.g. generational indices, like Bevy does).

You can't do possibly-erroneous pointer math on a C# object reference. You don't need to deal with the game life cycle AND the memory life cycle with a GC. In Unity they free the native memory when a game object calls Destroy() but the C# data is handled by the GC. Same with any plain C# objects.

To say it's the same as using array indices is just not true.

Re: Migrating away from Rust

#408

Post by whartung »

pornel wrote: post #316
mjr00 wrote: post #219

Earlier quoted context omitted.

> And yet, if making your own game engine makes it intellectually stimulating enough to actually make and ship a game, usually for near free, going 10x slower is still better than going at a speed of zero. Generally, I've seen the exact opposite. People who code their own engines tend to get sucked into the engine and forget that they're supposed to be shipping a game. (I say this as someone who has coded their own e…

Indeed there are people who want to make games, and there are people who think they want to make games, but want to make game engines (I'm speaking from experience, having both shipped games and keeping a junk drawer of unreleased game engines). Shipping a playable game involves so so many things beyond enjoyable programming bits that it's an entirely different challenge. I think it's telling that there are more Rust…

This does not apply just to games, but to most any application designed to be used by human beings, particularly complete strangers.

Typically the “itch is scratched” long before the application is done.

Re: Migrating away from Rust

#409

Post by jandrewrogers »

haberman wrote: post #328
jandrewrogers wrote: post #295

Earlier quoted context omitted.

> C instead of C++ because "it's faster" (spoiler: it probably doesn't matter for your project) If your C is faster than your C++ then something has gone horribly wrong. C++ has been faster than C for a long time. C++ is about as fast as it gets for a systems language.

> C++ has been faster than C for a long time. What is your basis for this claim? C and C++ are both built on essentially the same memory and execution model. There is a significant set of programs that are valid C and C++ both -- surely you're not suggesting that merely compiling them as C++ will make them faster? There's basically no performance technique available in C++ that is not also available in C. I don't thi…

This is really an “in theory” versus “in practice” argument.

Yes, you can write most things in modern C++ in roughly equivalent C with enough code, complexity, and effort. However, the disparate economics are so lopsided that almost no one ever writes the equivalent C in complex systems. At some point, the development cost is too high due to the limitations of the expressiveness and abstractions. Everyone has a finite budget.

I’ve written the same kinds of systems I write now in both C and modern C++. The C equivalent versions require several times the code of C++, are less safe, and are more difficult to maintain. I like C and wrote it for a long time but the demands of modern systems software are a beyond what it can efficiently express. Trying to make it work requires cutting a lot of corners in the implementation in practice. It is still suited to more classically simple systems software, though I really like what Zig is doing in that space.

I used to have a lot of nostalgia for working in C99 but C++ improved so rapidly that around C++17 I kind of lost interest in it.

Re: Migrating away from Rust

#410

Post by pnathan »

promiseofbeans wrote: post #302

One of the smartest devs I know built his game from scratch in C. Pretty complex game too - 3D open-world management game. It's now successful on steam. Thing is, he didn't make the game in C. He built his game engine in C, and the game itself in Lua. The game engine is specific to this game, but there's a very clear separation where the engine ends and the game starts. This has also enabled amazing modding capabilit…

This confused me as well. The scripting / engine divide is old and long standing.
Post reply on HN