Why is D's GC slower than GO's? (page 10)

On 10/29/2022 4:39 AM, IGotD- wrote: > None the less the argument with far/near to totally irrelevant today has nothing to do with the managed/raw pointer separation. I looked (briefly) at some online C++/CLI code. The __gc annotation looks just like __near/__far, and is applied in the same places.

On Saturday, 29 October 2022 at 20:03:46 UTC, Walter Bright wrote: > On 10/29/2022 4:39 AM, IGotD- wrote: >> None the less the argument with far/near to totally irrelevant today has nothing to do with the managed/raw pointer separation. > I looked (briefly) at some online C++/CLI code. The __gc annotation looks just like __near/__far, and is applied in the same places. Again mixing languages, __gc is from Managed C++, .NET 1.0 C++/CLI, .NET 2.0 onwards, uses ^ for reference types and gcnew for GC heap.

On Saturday, 29 October 2022 at 16:31:44 UTC, Alexandru Ermicioi wrote: > On Friday, 28 October 2022 at 21:11:00 UTC, H. S. Teoh wrote: >> On Fri, Oct 28, 2022 at 08:41:13PM +0000, Ali via Digitalmars-d wrote: [...] >>> [...] >> >> Maybe, just maybe, D does a lot of things right, in spite of doing a few >> things wrong (that people love to pick on and complain about)? ;-) >> >> [...] > > Maybe some of them do like it a lot, and that is the reason they complain. They are just dishonest with themselves, in the forum. Hmm, could be. You see the potential, and therefore want to actualize that potential, but you don't know how, so you complain.

On Saturday, 29 October 2022 at 19:55:31 UTC, Walter Bright wrote: > > Consider: > > strcpy(char* p, const(char)* q) > > Now consider managed: > > strcpy(char* p, const(char)* q) > strcpy(char* p, managed(const(char)*) q) > strcpy(managed(char*) p, const(char)* q) > strcpy(managed(char*) p, managed(const(char)*) q) > > It's quite different. > You are aware that you can always obtain a raw pointer from managed pointer right? Which be useful for FFI functions.

October 29, 2022

Re: Why is D's GC slower than GO's?

Posted by Adam D Ruppe
in reply to Walter Bright

Permalink

Adam D Ruppe

Posted in reply to Walter Bright

Permalink

On Saturday, 29 October 2022 at 19:55:31 UTC, Walter Bright wrote:
>      strcpy(char* p, const(char)* q)
>
> Now consider managed:

First, I proposed raw, not managed, let's be safe by default. Also remember what `alias this` does; an unprotected pointer (aka raw!(T*)) can implicitly cast to a protected pointer (aka T*). Third, think about what strcpy does. There's no need to change that signature at all - it is exactly the same as it is now, since it doesn't actually write to any pointers.

I'd assume managed by default - just like how arrays are bounds checked by default. If the programmer gets lazy, they get the 1% performance penalty but default protection. You have to opt out of the barrier with the `raw!T` (or the command line argument to turn it all off).

And since the barrier is only meaningful to pointer writes, it is completely useless with a const pointer because they are never written. So no need to draw a distinction there at all. Moreover, writing *through* a pointer is not the same as writing *to* the pointer. strcpy is writing to `char`s, not to `char*`, so even the same code is generated anyway. You don't have to barrier a `char`, the GC doesn't care if its value changes.

But even if it did write to the pointer, there'd be no need to change the signature, since the raw pointer implicitly converts to the managed pointer. And remember, the managed pointer only even generated different code if the *pointer itself* is actually written to, and moreover, we can even elide the checks if we know it is pointing to the same block, since the GC won't care about specifically where in the block it points, just that it points to the block. So even `a = a[1 .. $];` need not use a barrier. (I think.)

Arguably, all C functions should take raw pointers, but if the reference is borrowed, again it doesn't matter too much since you know there's another reference at the call site. So you might get away with ignoring that detail too. But still, the guiding principle is to be safe by default and allow people a chance to opt out with explicit action. Just like bounds checking in principle.

On Saturday, 29 October 2022 at 11:22:20 UTC, Guillaume Piolat wrote:

You would go ASICs.
But it's impractical so you could go FPGA.
But it's impractical so you could go GPGPU.
But it's impractical so you decide to go native.

I think this pattern is close the culture of C/C++, in the sense that many like to get a clear view of how their code is related to machine code instructions and memory layout. C/C++ is as close they feel they can get to machine code without taking the costs of dropping down to that level.

Rust and D have some of these, but also a large segment of users that are attracted to primarily high level programming. To a large extent I think this is a result of how these languages present them to newbies. If you present a high level layer to newbies you will grow a different user-base profile/culture. I am not sure if this is a good move as it is difficult to collect feedback that gives a clear focus on where to improve if the interests are diverse.

Maybe Zig is doing better than some competitors because it does not try to provide a high level experience (or do they?). Anyway, from a distance it looks like Zig is attracting a more more cohesive group of programmers with more overlapping expectations.

On 10/29/2022 1:11 PM, Paulo Pinto wrote: > Again mixing languages, > > __gc is from Managed C++, .NET 1.0 > > C++/CLI, .NET 2.0 onwards, uses ^ for reference types and gcnew for GC heap. What's the difference between __gc* and ^ ?

On 10/28/22 13:41, Ali wrote: > stop being sympathetic towards D And stop being sympathetic towards C++. > , yes, it could have been in a better > place, but it is not, it will not, it is what it is I completely agree. D has been here for so long and it will still be here for even longer. > sympathy towards D will change nothing Symphaty towards unicorns will change nothing either. > Walter is a nice guy, and you wish his language did better, Not at all. The language is just fine. Very usable... because... I use it with ease... > you wish he > was in a better place, but nice people dont always win, it is what it is Agreed. > I dont know what is it exactly about D that drive so many people to have > that much sympathy for it Humans... Flies will gravitate towards the popular, but some of us will value merit. Ali

On 10/29/2022 1:26 PM, IGotD- wrote: > You are aware that you can always obtain a raw pointer from managed pointer right? Which be useful for FFI functions. Yes, and you can also always obtain a far pointer from a near one. But there's always a cost, otherwise there'd be no point to having near pointers. If C++/CLI nailed it, why has C++ in general not adopted it? Why has nobody create a C compiler, but with GC? What is the point of Rust if GC is the answer?

On 10/28/22 10:17, Ali wrote: > I think many languages, provide the benefits of metaprogramming, without > necessarily calling it metaprogramming The way I understand it, metaprogramming in languages like D are decided at compile time. That's why C++ has been shown to be faster than C. Bjarne Stroustrup has an example here: https://www.stroustrup.com/new_learning.pdf In short, sort() in C++ is faster than C because there is no dispatching through a function pointer at runtime. In languages like D, the deal is sealed at compile time. D allows optimizations with compile-time introspection as well. > for example: > 1. Tcl everything is a string, and you have the eval function Which means, everything is parsed at run time, right? Perhaps they use JIT to amortize some compilation away. > 2. Any dynamic language, that have an eval function, and where you can > add a config file in code to your programs Same as Tcl: Must be slow. > 3. lisp, every this is a list, and you can easily pass a function as a > parameter At least the passed function needs to be called. There is a function call dispatch there. > 4. any language that have functions as first class objects and allow you > to pass functions as parameters Same: Function pointer dispatch. > 5. any object oriented language, and it all really depend on how good > your object model is Same. Or worse: Even objects need vtbl dispatch there. In contrast, D's range algorithms nail the implementation down to exact types that you have. No dynamic dispatching of any kind. There is on contest really... > 6. languages with metaobject I don't know that but perhaps they are better is some sense. (?) > So can you give examples, of how D does those things better, or does > things that others cant, code examples I don't need to give any example at this point. Maybe you have further questions? Ali

Forums