undefined | Better HN

0 pointsMichaelGG12y ago0 comments

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.

0 comments

11 comments · 3 top-level

marshray12y ago· 4 in thread

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?

MichaelGGOP12y 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.

marshray12y 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.

1 more reply

fleitz12y ago

Stack allocation is kind of like inlining, the more you use it the faster your program gets.

MichaelGGOP12y 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).

fleitz12y ago· 2 in thread

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).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.

kibwen12y 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.

MichaelGGOP12y 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.

cmrx6412y ago· 2 in thread

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.

MichaelGGOP12y 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.

cmrx6412y 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.

1 more reply

j / k navigate · click thread line to collapse

0 comments

11 comments · 3 top-level

marshray12y ago· 4 in thread

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?

MichaelGGOP12y ago

marshray12y ago

Yes, absolutely, allocate everything possible on the stack.

1 more reply

fleitz12y ago

Stack allocation is kind of like inlining, the more you use it the faster your program gets.

MichaelGGOP12y ago

fleitz12y ago· 2 in thread

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).as...

kibwen12y 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.

MichaelGGOP12y 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.

cmrx6412y ago· 2 in thread

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.

MichaelGGOP12y ago

cmrx6412y ago

String literals are stored in the ro section, as one might expect.

1 more reply

j / k navigate · click thread line to collapse