Hi all!

Is it correct that D produces executables that depend on libc?

While this approach avoids a certain amount of maintenance cost doesn't it limit D's possibility to outdo C on the lowest level?

Honey

On Monday, 19 June 2017 at 20:20:23 UTC, Honey wrote:
> Is it correct that D produces executables that depend on libc?

Usually yes, since that makes sense for most programs on operating systems, but you can pull it out if you want to for a specialized task. (Really, same boat C is in.)

On Monday, 19 June 2017 at 20:26:43 UTC, Adam D. Ruppe wrote:
> On Monday, 19 June 2017 at 20:20:23 UTC, Honey wrote:
>> Is it correct that D produces executables that depend on libc?
>
> Usually yes, since that makes sense for most programs on operating systems, but you can pull it out if you want to for a specialized task. (Really, same boat C is in.)

Thanks, Adam!

To elaborate on my second point: if one compares, say, FreeBSD's libc [1] with glibc [2] it is pretty obvious that not all implementations are optimized to the same degree.

Does it make sense - at least in cerain cases - to provide and use a D implementation that is fast on all platforms, instead?

[1] https://svnweb.freebsd.org/base/head/lib/libc/
[2] https://sourceware.org/git/?p=glibc.git;a=tree;hb=HEAD

On 6/19/17 5:01 PM, Honey wrote:
> On Monday, 19 June 2017 at 20:26:43 UTC, Adam D. Ruppe wrote:
>> On Monday, 19 June 2017 at 20:20:23 UTC, Honey wrote:
>>> Is it correct that D produces executables that depend on libc?
>>
>> Usually yes, since that makes sense for most programs on operating systems, but you can pull it out if you want to for a specialized task. (Really, same boat C is in.)
> 
> Thanks, Adam!
> 
> To elaborate on my second point: if one compares, say, FreeBSD's libc [1] with glibc [2] it is pretty obvious that not all implementations are optimized to the same degree.
> 
> Does it make sense - at least in cerain cases - to provide and use a D implementation that is fast on all platforms, instead?

It does, but it depends on what you want to replace. What specifically are you looking for?

IIRC, Tango did not depend on libc at all. It only used system calls. So it certainly is possible.

-Steve

On Monday, 19 June 2017 at 21:35:56 UTC, Steven Schveighoffer wrote:
> IIRC, Tango did not depend on libc at all. It only used system calls. So it certainly is possible.

How did they invoke those system calls? They are usually access via libc on POSIX systems, so you don't have to implement accessing e.g. vdso on Linux yourself.

On Monday, 19 June 2017 at 21:35:56 UTC, Steven Schveighoffer wrote:
> It does, but it depends on what you want to replace. What specifically are you looking for?

I might need a fast variant of memcmp. Writing it in D seems to be the natural choice. I see no reason why it should be slower than other well optimized C implementations. It will probably be faster than implementations in not so much tuned standard C libraries.

Actually replacing memcmp does not seem worth the effort. However, I was wondering whether D could and should be used to replace more C 'legacy' - for fun and profit. ;-)


> IIRC, Tango did not depend on libc at all. It only used system calls. So it certainly is possible.

I heard that Go's standard library is based on a similar approach.

Not depending on libc at all might serve as a marketing instrument as well.

On 6/19/17 5:45 PM, Moritz Maxeiner wrote:
> On Monday, 19 June 2017 at 21:35:56 UTC, Steven Schveighoffer wrote:
>> IIRC, Tango did not depend on libc at all. It only used system calls. So it certainly is possible.
> 
> How did they invoke those system calls? They are usually access via libc on POSIX systems, so you don't have to implement accessing e.g. vdso on Linux yourself.

I may have misspoke. I mean they didn't depend on the library itself. I think they do depend on the C wrappers.

So for instance, they didn't use FILE *, but instead used read/write/recv/send.

I don't know what's involved in creating those wrappers, but I can't imagine it's difficult to do with D (it's probably actually easier than in C/assembly).

-Steve

On Mon, Jun 19, 2017 at 07:29:46PM -0400, Steven Schveighoffer via Digitalmars-d-learn wrote:
> On 6/19/17 5:45 PM, Moritz Maxeiner wrote:
> > On Monday, 19 June 2017 at 21:35:56 UTC, Steven Schveighoffer wrote:
> > > IIRC, Tango did not depend on libc at all. It only used system calls. So it certainly is possible.
> > 
> > How did they invoke those system calls? They are usually access via libc on POSIX systems, so you don't have to implement accessing e.g. vdso on Linux yourself.
> 
> I may have misspoke. I mean they didn't depend on the library itself. I think they do depend on the C wrappers.
> 
> So for instance, they didn't use FILE *, but instead used read/write/recv/send.
> 
> I don't know what's involved in creating those wrappers, but I can't imagine it's difficult to do with D (it's probably actually easier than in C/assembly).
[...]

The downside of that is that then we can no longer leverage the work done by libc authors to interface with that particular OS / platform. Meaning we have to maintain this low-level code ourselves, which includes potentially keeping up with OS-level changes that would otherwise be transparent had we used the libc wrappers. Sadly, we're not yet in the day when libd authors would do this for us with every new OS that comes out. :-D


T

-- 
Talk is cheap. Whining is actually free. -- Lars Wirzenius

On Monday, 19 June 2017 at 23:29:46 UTC, Steven Schveighoffer wrote:
> I don't know what's involved in creating those wrappers, but I can't imagine it's difficult to do with D (it's probably actually easier than in C/assembly).

Not difficult, but a tedious amount of work for no inherent benefit:
You would have to recreate the correct system call calling semantics for every operating system / hardware combination that D is supposed to run on.
I suggest reading [1] and [2] to get a feeling of the workload *just* for Linux.
My unsolicited opinion: Unless someone pays you (for whatever reason) to explicitly not use a libc, just use a well tested libc for system calls and be done with it.

[1] http://man7.org/linux/man-pages/man2/syscalls.2.html
[2] http://man7.org/linux/man-pages/man7/vdso.7.html

On Monday, 19 June 2017 at 21:01:35 UTC, Honey wrote:
> On Monday, 19 June 2017 at 20:26:43 UTC, Adam D. Ruppe wrote:
>> On Monday, 19 June 2017 at 20:20:23 UTC, Honey wrote:
>>> Is it correct that D produces executables that depend on libc?
>>
>> Usually yes, since that makes sense for most programs on operating systems, but you can pull it out if you want to for a specialized task. (Really, same boat C is in.)
>
> Thanks, Adam!
>
> To elaborate on my second point: if one compares, say, FreeBSD's libc [1] with glibc [2] it is pretty obvious that not all implementations are optimized to the same degree.
>
> Does it make sense - at least in cerain cases - to provide and use a D implementation that is fast on all platforms, instead?
>
> [1] https://svnweb.freebsd.org/base/head/lib/libc/
> [2] https://sourceware.org/git/?p=glibc.git;a=tree;hb=HEAD

The issue with that is that you assume:

1) that a complete libc replacement can be created from scratch
2) that a correct libc replacement can be created from scratch
3) that a better libc replacement can be created from scratch
4) that this replacement can be maintained for years to come on all plateforms

All those points are certainly theoretically possible, but getting all 4 at once isn't a small task. Point 2 and 3 in particular: whatever your libc is it's been tested, reflected upon and optimized for years by good programmers. There is absolutely no reason to throw away this work. Even if it was practical to do that and that the developper was confident enough that he can do better than libc to start working on it, point 4 would be out of reach given the current state of affairs.

So, while replacing specific C functions by D implementations where the gain is clear seems like a good idea to me, dropping the dependency on libc seems more like a risky gamble than anything.