4 ms·

No, but Rust is a contender.

• shocks 13y ago
  Do you want to offer some reasoning for your enlightening statement?
  • MichaelGG 13y ago
    From my cursory review of Rust, they're getting a lot of things right. One small example: in C#, you can't properly stack-allocate things like strings, because "reference types" get alloc'd on the heap, end of story. A function might decide to store a reference later, so stack alloc isn't possible. The CLR implementation doesn't do escape analysis. In Rust, the type system encompasses things like who owns a pointer, so you can keep memory management simple, while choosing performance-oriented paths when needed. The CLR itself is actually fine with a lot of such things (nothing stops you from stack allocating a string "by hand"), it just doesn't help you out. IL is pretty expressive and can translate C in a fairly straightforward fashion. So "C#" by itself has some drawbacks, but they could be patched over with some interop libraries or language extensions.
    • fleitz 13y ago
      If by string you mean array of char then it's perfectly possible to stack allocate an array of char in C#. http://msdn.microsoft.com/en-us/library/aa664785(v=vs.71).aspx http://msdn.microsoft.com/en-us/library/aa664785(v=vs.71).as... And seriously, it's not like everything in the linux kernel is stack allocated. The stack runs out of memory as well so it's not as if stack allocation is some magical place with out resource constraints. Since we deal with processors with caches and lots of other variable timing issues you don't even really get deterministic timing either.
      • MichaelGG 13y ago
        No, I mean to allocate a System.String instance that you can pass to other functions. Or a managed array (say, the char array you pass to String.Split). Or any other reference type.
      • kibwen 13y ago
        > The stack runs out of memory as well I agree with the rest of what you're saying, but I want to point out that Rust stacks are growable (at least in theory), so you won't run out of stack until you're OOM.
    • marshray 13y ago
      I'm a fan of Rust, but the practice of allocating strings on the stack in fixed-sized buffers is one of the biggest mistakes of C culture. Perhaps you could just picked a poor example?
      • fleitz 13y ago
        Stack allocation is kind of like inlining, the more you use it the faster your program gets.
        • MichaelGG 13y ago
          I know this may have been tongue-in-cheek, but on the CLR, inlining functions makes a massive difference. That is, using F#'s forced inlining capabilities to generate massive functions (many KB of IL) resulted in much better runtimes than having even a couple of small functions called (which "should" be inlined by the CLR; MS tells us we should just rely on the JIT for these cases).
      • MichaelGG 13y ago
        That's more a problem of unsafe manipulation. Allocating a safe length-prefixed string should not be an issue. Or, arrays. Take .NET's String.Split function which takes a char array. If you pass in a new array each time, there's a whole heap-alloc for no reason. Or Tuples. Or closure objects. Things like that do add up (GC cost, even though small short-lived objects are fast, it isn't zero), and escape analysis/stack alloc can make a huge difference, sometimes. I've come to this conclusion while writing a "high-speed" indexer program where manually avoiding tiny allocations in certain areas provided double-digit percent improvements. I wish I had kept proper notes.
        • marshray 13y ago
          Yes, absolutely, allocate everything possible on the stack. But strings are the poster child for dynamic memory allocation. We only very rarely know a good upper limit on the size of the actual strings at the time the code is written, yet C programmers have shipped endless numbers of bugs thinking they did.
    • cmrx64 13y ago
      Rust doesn't have stack allocated strings, I have no idea what you're talking about. We have string slices, but there's no way to stack allocate those, they don't own their allocation.
      • MichaelGG 13y ago
        I must have misread then. I thought in Rust there were various pointer types denoting ownership, and one of them was callstack-scoped (borrowed pointer?), meaning it could be backed by stack allocated memory.
        • cmrx64 13y ago
          Well, yes, borrowed pointers can point onto the stack, but we don't have string values that can live on the stack, not really. String slices, denoted as `&str`, can point into the stack if you construct them from a `[u8, ..N]` (a fixed-length vector). String literals are stored in the ro section, as one might expect.
          • MichaelGG 13y ago
            Right, literals, but for example, suppose I'm creating a ton of temporary strings (e.g. appending a filename to get a full path and calling touch on it) - in C#, I'm going to heap-alloc a new string for each call. With Rust, I _could_ compose it into a stack-alloc'd buffer, and pass it any function taking a string it doesn't need to own, correct?
            • dbaupp 13y ago
              Yes, you can put a fixed-length buffer of bytes (e.g. `[u8, .. 1024]` is 1kb) on the stack and use that as the backing vector for the string.