Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future of framework dependencies #80

Open
RossNordby opened this issue Sep 25, 2019 · 12 comments

Comments

@RossNordby
Copy link
Member

commented Sep 25, 2019

.NET Core 3.0 is now out, and it seems like a good time to collect information for the future of bepuphysics v2's dependencies.

At the moment, the library targets .NET Standard 2.0. It can run on .NET Framework, .NET Core, mono, and in theory any other runtime supporting the standard.

However, .NET Standard 2.0 is missing a few features which would be handy to have for performance and simplicity. 2.1 includes some of these features, but requires pretty recent platforms. .NET Framework 4.8, for example, will not support .NET Standard 2.1.

Further, even .NET Standard 2.1 is missing the platform specific intrinsics (at least as far as I can tell- let me know if I'm wrong about this!). The only full featured path appears to be .NET Core 3.0 (and later, the unified .NET 5).

So, the options:

  1. .NET Standard 2.0: compatibility with .NET Framework and current Unity implementation, miss out on mild performance improvements available in new APIs. (The engine already uses Vector<T> extensively, so the benefit of platform dependent intrinsics isn't enormous. But it's not zero either.) Notably, runtime bugs in Unity currently block full functionality, and while workarounds can make parts of it work, it tends to be so slow that it's mostly pointless.
  2. .NET Standard 2.1: Current .NET Framework versions unsupported, Unity unsupported (until later versions). MathF and other small tweaks become available.
  3. .NET Core 3.0: Gain access to platform dependent intrinsics, lose support for every other platform.

The obvious choice is to build for multiple targets, but this is a case where each additional target is enormous, and maintaining legacy paths would be painful. I'd like to see where people are using the engine to see if trimming down the support targets is possible.

Questions for users:

  1. What are you targeting now with bepuphysics v2?
  2. Would your project be compatible with .NET Standard 2.1?
  3. How about .NET Core 3.0?
  4. Has anyone managed to use it within unity? (And if so, could you elaborate on how? :))

(It's worth noting that, even if the decision was made to, say, only focus on .NET Core 3.0, it would be a while before I'd actually work on that, let alone finish it. This is primarily a medium-long term concern.)

@vpenades

This comment has been minimized.

Copy link

commented Sep 25, 2019

As a business, you never know when a client is going to come through the door and tell "hey, that cool project you have on windows? it would be nice if you can run it on Android, or in Windows XP" (which is something we've been actually asked)

Performance is important, but what's the point of a project if it cannot be used? so that answers the question: compatibility goes before performance.

As you say, the ideal solution would be multiple targets, but it's a lot of maintenance for a single developer. It's happening to me too in my projects.

BepuPhysics seems already very efficient and performant, so I would stick with NetStandard2.0.... I don't think it's worth to loose several platforms for the sake of gaining 15% performance.

@KakCAT

This comment has been minimized.

Copy link

commented Sep 25, 2019

I'm not using bepu 2 (and unfortunately maybe I will never use it, as my current project may be my last solo project and I decided to stick with bepu 1) but supposing I would, my requirements would be working nicely with PS4 and Switch and able to work side by side with MonoGame (it does now).

I don't know how this exactly translates as answers to your questions, but I suppose I'm also in the compatibility bandwagon.

@lidgren

This comment has been minimized.

Copy link

commented Sep 25, 2019

.NET Core 3 all the way.

@Alan-FGR

This comment has been minimized.

Copy link

commented Sep 26, 2019

I'd vote for net standard 2.1 atm but since it's something for the long run then yeah net core 3 imho.

@phende

This comment has been minimized.

Copy link

commented Sep 29, 2019

It seems the reason why bepuphysics2 exists and is so different from v1 is about squeezing the best performance out of .Net, and .NET Standard 2.1 does not bring too much in that area. Or does it ?

So what about branching the current state as .NET Standard 2.0 and only applying critical bug fixes there, then driving master toward .NET Core 3 ? Would a compile-time compatibility shim for intrinsics be complicated, for where intrinsics are not supported ?

I don't have older projects to maintain so am obviously biased... :-)

@Alan-FGR

This comment has been minimized.

Copy link

commented Sep 29, 2019

So what about branching the current state as .NET Standard 2.0 and only applying critical bug fixes there, then driving master toward .NET Core 3 ?

Branching a stable version doesn't sound like a good idea at this point imho.

@phende

This comment has been minimized.

Copy link

commented Sep 29, 2019

Branching a stable version doesn't sound like a good idea at this point imho.

Right. Another option then is to branch the current to become bepuphysics v2.1 or v3, that achieves the same effect and does not matter much. Only depends on what path @RossNordby likes to follow.

@RossNordby

This comment has been minimized.

Copy link
Member Author

commented Sep 29, 2019

I should mention that the engine is pretty much guaranteed to, at some point, adopt platform dependent intrinsics for my own purposes. It's just a question of when and what I do about legacy at that point. For example, if I wait long enough that .NET 5 becomes the de facto standard and mostly unifies mono and coreclr, there would likely be little point in trying to maintain .NET Framework compatibility. Unity might take a while longer, but... it's effectively unsupported right now anyway.

(Is anyone stuck using the legacy .NET Framework with bepuphysics v2? Could you describe your situation? And do you think that situation will last into late next year with .NET 5?)

It seems the reason why bepuphysics2 exists and is so different from v1 is about squeezing the best performance out of .Net, and .NET Standard 2.1 does not bring too much in that area. Or does it ?

Not too much (unless I'm wrong about the platform dependent intrinsics being absent). MathF's inclusion does help clean up a few scalar paths a little.

@RossNordby

This comment has been minimized.

Copy link
Member Author

commented Sep 29, 2019

Would a compile-time compatibility shim for intrinsics be complicated, for where intrinsics are not supported ?

I have toyed with the idea of a custom tool to do some very simple codegen without some of the nastiness of text templates, but then I have to slap myself because I already have an infinitely long to-do list :)

Depending on the JIT, it may be possible to have zero overhead JIT-time specialization. Things like Avx.IsSupported are already JIT intrinsics, so that part is actually pretty easy. The harder part is ensuring there is no wonkiness in the generated assembly caused by things like wrapper structs, various in-theory-free memory casts, or enregistration blocking. RyuJIT has made a lot of progress on this front (most of the core issues may have already been resolved, I haven't actually looked in a few months). If that pans out, then it would be not-absolutely-horrible to have a ScalarWide type alongside Vector3Wide and friends that abstracts the underlying vector API. It would still require revisiting pretty much every vectorized implementation, but, that's going to happen no matter what.

@vpenades

This comment has been minimized.

Copy link

commented Sep 30, 2019

It is not my personal case, but for example, MonoGame is trying hard to keep compatibility with Net45, because apparently, most console SDKs that support c# are stuck in Net45. And apparently they move forward into adopting newer versions really slowly.

MonoGame has a weird build system just because that, the public repository has the code for most "public" platforms, but then there's a private repository, for which you need to have a console developer ID, that has the code that targets the consoles (closed source under NDAs). So, whenever someone sends a pull request upgrading some framework to a newer version, it's immediately rejected because it might break the consoles code.

Given that BepuPhysics is clearly aiming for videogames, it could be a waste if it blocks itself from consoles. so I would suggest you to ask some developers working with consoles to know more about the console frameworks life cycle so you know what to expect and which frameworks are/will be supported.

@hawkerm

This comment has been minimized.

Copy link

commented Oct 1, 2019

Considering the lack of maintained C# physics engines, bepu looks really promising for adoption on a project I'm working on.

However, I'm planning to not only target UWP, but also WASM using Uno. I know the earlier doesn't support .NET Standard 2.1 yet though. I'm also not sure how that would effect WASM support either, though I'm not sure if anyone has tried bepu in WASM yet?

@RossNordby

This comment has been minimized.

Copy link
Member Author

commented Oct 2, 2019

I'm not sure if anyone has tried bepu in WASM yet?

I haven't seen it- it would be an interesting experiment given the heavy reliance on vectorization. I assume it wouldn't vectorize yet (unless the transpilers and WASM SIMD proposals are further along than I thought), but the scalar fallback may still have acceptable performance if it can handle the compile-time branching properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.