61–67 of 67 posts
Do you think this exercise has taught you anything that could make fil c itself better?
Yeah I really need to have a better fix for how I handle unions. And the fact that having outline calls to methods of value objects is so expensive
Is this tied to unions? Or otherwise, when does this happen? I don't see the connection w/ invisicaps or &c
Really interesting read, especially after I released the initial version of my own interpreter which is also an AST-walking interpreter. My main goal was to understand at a basic level what it takes to build an interpreted programming language. I didn't want any optimisation complexities and just focused on being able to understand my own Rust code. I was surprised by the performance I got simply by using my favourit…
> as a bonus, since Rust takes care of all the ownership > and lifetimes, I don't need a garbage collector.
I can imagine GluconScript's memory handling comes at a cost, even if the tradeoff of using a borrow checker is well worth it. Was that your experience?
Relatedly, since you commented there has been submission about garbage collectors in Rust ("Garbage Collection Without Unsafe Code"):
Really interesting read, especially after I released the initial version of my own interpreter which is also an AST-walking interpreter. My main goal was to understand at a basic level what it takes to build an interpreted programming language. I didn't want any optimisation complexities and just focused on being able to understand my own Rust code. I was surprised by the performance I got simply by using my favourit…
GluconScript looks cool, but this sounds too good to be true: > as a bonus, since Rust takes care of all the ownership > and lifetimes, I don't need a garbage collector. I can imagine GluconScript's memory handling comes at a cost, even if the tradeoff of using a borrow checker is well worth it. Was that your experience? Relatedly, since you commented there has been submission about garbage collectors in Rust ("Garba…
As far as I researched, only closures could generate dangling references and therefore need memory cleanup, but only if I allowed closures to access their environment (variables and functions) by reference / mutable reference.
To avoid this and simplify both my code as well as the mental model for the users of GluonScript, as of now, closures capture their environment by cloning it immutably. There's an increased memory usage with all the copying of the environment but there are never references to something that isn't being used anymore and therefore no need for a GC. At the end of the day all values captured by closures are owned Rust values that are dropped by Rust when no longer in scope.
So this can lead to high memory usage in hot loops but it can't lead to memory leaks.
How's your experience with Fil-C been? Is it materially useful to you in practice?
I’m biased since I’m the Fil. It was materially useful in this project. - Caught multiple memory safety issues in a nice deterministic way, so designing the object model was easier than it would have been otherwise. - C++ with accurate GC is a really great programming model. I feel like it speeds me up by 1.5x relative to normal C++, and maybe like 1.2x relative to other GC’d languages (because C++’s APIs are so rich…
This will greatly reduce coordination bugs in parallel programs and may even speed things up.
Earlier quoted context omitted.
Yeah I really need to have a better fix for how I handle unions. And the fact that having outline calls to methods of value objects is so expensive
> And the fact that having outline calls to methods of value objects is so expensive Is this tied to unions? Or otherwise, when does this happen? I don't see the connection w/ invisicaps or &c
“Escape” is defined very loosely; it currently means: some function other than the one that owns the stack allocation needs a pointer to that allocation.
For example even if you could prove that `bar(Value* p)` never stashes p anywhere, the fil-C compiler will currently heap allocate that value anytime bar is called. The one exception is if bar had already been inlined, and so from the FilPizlonator’s perspective there isn’t even a call.
This is clearly dumb and fixable. It’s dumb because lots of functions aren’t worth inlining but their body is analyzable. Slow paths are like that. It’s fixable because those slow paths - and lots of code like them - takes ptrs as arguments and then obviously just uses them for loads and stores but doesn’t escape them any further.
You’ll sometimes hear me say that Fil-C is nowhere near as optimal as it could be. This is just one example of that
Earlier quoted context omitted.
I’m biased since I’m the Fil. It was materially useful in this project. - Caught multiple memory safety issues in a nice deterministic way, so designing the object model was easier than it would have been otherwise. - C++ with accurate GC is a really great programming model. I feel like it speeds me up by 1.5x relative to normal C++, and maybe like 1.2x relative to other GC’d languages (because C++’s APIs are so rich…
If I may (and correctly understand what is going inside Fil-C), it would be not so hard to add support for software transactional memory by adding some library calls. This will greatly reduce coordination bugs in parallel programs and may even speed things up.
- STM interacts badly with any interesting effects (like IO)
- STM interacts badly with locks (C and C++ use locks implicitly, because they’re in libc and libc++)
- STM performs badly
- STM is harder to use than locks
Earlier quoted context omitted.
I’m biased since I’m the Fil. It was materially useful in this project. - Caught multiple memory safety issues in a nice deterministic way, so designing the object model was easier than it would have been otherwise. - C++ with accurate GC is a really great programming model. I feel like it speeds me up by 1.5x relative to normal C++, and maybe like 1.2x relative to other GC’d languages (because C++’s APIs are so rich…
Are you using malloc + GC in preference to smart pointers, and if so why? I thought Fil-C was just C not C++? It doesn't seem like that is necessarily a performance win, especially since you could always use a smart pointer's raw pointer (preferably const) in a performance critical path.
Smart pointers give you reference counting at best. Language implementations tend to have a lot of reference cycles, so you need actual GC (or a very sophisticated kind of manual memory management)