bengarney · HackerTrans

10 ngày trướcdiscuss

secret | REMOTE | Contract to full time | Any country

I need an experienced Unity graphics specialist to reboot a beloved and unique simulation game IP as part of a small dedicated team. You are comfortable writing terrain, foliage, atmospherics, volumetrics, particle system from scratch, along with more typical URP/SRP dark arts + fell workings. You are OK with an opinionated codebase that largely sidesteps standard Unity stuff.

Apply by: e-mailing me at (my first name) at theengine.co

bengarney

6 tháng trướcdiscuss

Here is a thought experiment (for devs who buy into package managers). Take the hash of a program and all its dependency. Behavior is different for every unique hash. With package managers, that hash is different on every system, including hashes in the future that are unknowable by you (ie future "compatible" versions of libraries).

That risk/QA load can be worth it, but is not always. For an OS, it helps to be able to upgrade SSL (for instance).

In my use cases, all this is a strong net negative. npm-base projects randomly break when new "compatible" version of libraries install for new devs. C/C++ projects don't build because of include/lib path issues or lack of installation of some specific version or who knows what.

If I need you to install the SDL 2.3.whatever libraries exactly, or use react 16.8.whatever to be sure the app runs, what's the point of using a complex system that will almost certainly ensure you have the wrong version? Just check it in, either by an explicit version or by committing the library's code and building it yourself.

bengarney

10 tháng trướcdiscuss

The world falls into two categories for me. "Must be fast" and "I don't care (much)". C/C++ is ideal for the first one, and C# is awesome for the second.

My argument isn't that C# is bad or performance is unachievable. It's that the mental overhead to write something that has consistent, high performance in C/C++ is very low. In other words, for the amount of mental effort, knowledge, and iteration it takes to write something fast + maintainable in C#, would I be better served by just writing it in C/C++?

The linked assembly is almost certainly non-optimal; compare to -O3 of the C version: https://godbolt.org/z/f5qKhrq1G - I automatically get SIMD usage and many other optimizations.

You can certainly make the argument that if X, Y, Z is done, your thing would be fast/faster. But that's exactly my argument. I don't want to do X, Y, Z to get good results if I don't have to (`return ref Unsafe.Add(ref MemoryMarshal.GetArrayDataReference(array), (nuint)index);` and using/not using `[MethodImpl(MethodImplOptions.AggressiveOptimization)]` are non-trivial mental overhead!).

I want to write `foo.bar` and get good, alloc free, optimized results... and more importantly, results that behave the same everywhere I deploy them, not dependent on language version, JIT specifics, etc.

If I was operating in a domain where I could not ever take the C/C++ path, these features of C# are of course very welcome. And in general more power/expressiveness is very good. But circling back, I wonder if my energy is better spent doing a C version than contorting C# to do what I want.

bengarney

10 tháng trướcdiscuss

It is, but it isn't quite the same as C, either. That is to say, there is some semi-unknowable stack of stuff happening under the covers.

I will predict the future: you will pull up the JIT assembly output to make the case that they output similarly performant assembly on your preferred platform, and that you just have to do X to make sure that the code behaves that way.

But my problem is that we are invoking the JIT in the conversation at all. The mental model for any code like this inevitably involves a big complex set of interacting systems and assumptions. Failure to respect them results in crashes or unexpected performance roadblocks.

bengarney

10 tháng trướcdiscuss

I increasingly wonder if writing and binding performance critical things in C/C++ would be less overall effort. Performant zero-alloc C# vs C/C++ is backdoor magic vs first class language support. Boxing gloves vs. surgical gloves.

C# _can_ do this! But I face many abstractions: special perf APIs, C#, IL, asm. Outcomes will vary with language version, runtime version, platform, IL2CPP/Burst/Mono/dotnet. But C/C++ has one layer of abstraction (the compiler), and it's locked in once I compile it.

I want to do the thing as exactly and consistently as possible in the simplest way possible!

A build environment that compiles .cpp alongside .cs (no automatic bindings, just compilation) would be so nice for this.

----

Example of what I mean regarding abstractions:

  void addBatch(int *a, int *b, int count)
  {
    for(int i=0; i<count; i++) 
      a[i] += b[i]; 
  }

versus:

    [MethodImpl(MethodImplOptions.AggressiveOptimization)]
    public static void AddBatch(int[] a, int[] b, int count)
    {
        ref int ra = ref MemoryMarshal.GetArrayDataReference(a);
        ref int rb = ref MemoryMarshal.GetArrayDataReference(b);
        for (nint i = 0, n = (nint)count; i < n; i++)
            Unsafe.Add(ref ra, i) += Unsafe.Add(ref rb, i);
    }

(This is obviously a contrived example, my point is to show the kinds of idioms at play.)

comments