View mode: basic / threaded / horizontal-split · Log in · Help
April 07, 2006
Re: On processors for D ~ decoupling
Walter Bright wrote:
> kris wrote:

I see you snipped the questions about trying to understand the need for 
Ares? I thought those were realistic, reasonable, and pertinent 
questions in the search to understand why you can't understand Ares exists.

Are they just not important enough to warrant attention? Here they are 
again:

<repost>

Kris: Why do you think Ares exists anyway?

Walter: I'm trying to understand.

Kris: Ah. That makes some sense now ~ so, you're saying you don't see 
any need for a better library? That you're trying to understand what 
such a need might be?

</repost>

Those are important questions, since they'll help clarify the apparently 
vast divide between what you think of as a library, and what I do. I 
doubt very much that I'm alone upon that sea of confusion. If I were, 
Ares would not exist. I feel its important for you to be open about your 
perspective on "alternate" libraries vs Phobos ~ after all, there's a 
lot of people putting a lot of effort into making those available ...

BTW: the phrase "better library" is used there because that what Ares 
was designed to be. I now realise that you may have interpreted that as 
some kind of an "insult" to Phobos. Many pardons.


> For printf, the actual coupling problem is:
> 
> 1) It pulls in floating point formatting code. This turns out to not be 
> correct.

Mea culpa; easy mistake to make when there's nothing else referencing 
FP, wouldn't you say? Who might have guessed it were std.string instead 
of printf() ?


> 2) It's bloated. The bloat turns out to be 4K code - a big problem on an 
> 8 bit machine to be sure, but not on a 32 bit one.
> 3) It pulls in the entire C I/O system. This turns out to also not be 
> correct. It pulls in a reasonable portion of it.

Smoke & mirrors: If the C IO were not already leaking in via a number of 
other holes in the boat, then the reference within object.d would be 
solely responsible for pulling in everything that printf references. 
This does amount to a rather large majority of the C IO subsystem, as 
you know. Yes, you've made it perfectly clear that you have no interest 
in even trying to see any relationship therein.


> 4) It should be replaceable/hookable. Yes, it is.

By stubbing out dependencies? That's not what I'd call good design. If 
you think it is, then we can agree to disagree.


> On the other hand, the advantages of having a print in Object are:
> 
> 1) Every object can be relied upon to have some sort of print method.

If that has such an immeasurable value, why is it not used more? I 
submit this particular "reason to exist" is of questionable merit. D 
deserves better debugging support than object.print() ~ there's a decent 
logging package in mango.log ... doesn't even allocate memory.


> 2) Substituting a toString() is problematic because it usually requires 
> extra allocation and hence double buffering - so most I/O systems avoid 
> such designs. 

I see. The type of trivial, lazy, and inflexible debugging-output 
represented by object.print() needs to avoid double buffering at all costs?


> Also, the print is often used for debugging, and having it 
> be forced to use an allocation can upset what one is trying to debug - 
> by causing a gc collection cycle, for example.

Pardon me; std.string is the one of the worst offenders in terms of 
wasteful memory allocation that I've seen in decades. It appears that 
every single toString() method allocates from the heap, Walter. I would 
have mentioned this before, but we couldn't even get past the introduction.

To use your own words "Also, the print is often used for debugging, and 
having it be forced to use an allocation can upset what one is trying to 
debug - by causing a gc collection cycle, for example.".

I'm sure you realise that print() method invokes toString(), quite 
possibly resulting in calls to std.string.toString()? Which does wholly 
unecessary memory allocations? Pardon me, but std.string is hardly the 
shining light to be held aloft in such matters.


> 3) It being synchronized with C's IO means it doesn't screw up when 
> mixed with normal IO code.

That's really stretching: you don't need printf() to synchronize with 
normal IO. Use one of the lower layers instead, since none of the 
formatting options are actually used ~ as you know. This is a good 
example of using an "expensive" library function where a "less costly" 
one would suffice perfectly well. Again, the functionality is of 
questionable value anyway.


> No, I did not ignore it. I don't feel it's productive to rewrite the 
> functions in std.string in each module. std.string is not a burdensome 
> piece of code. 

It is most certainly burdensome, Walter. Allocating memory is one of the 
most expensive things one can do in this realm ~ std.string does it with 
gay abandon. How does that fit with your position?


> I'll agree with you that pointless and gratuitous coupling should be 
> avoided, but that is not the case with the two examples we're discussing.

I submit that printf() within object.d is gratuitous and almost entirely 
pointless. And not even used appropriately. There's fair reason why one 
won't see that kind of appendage in mainstream designs.

The coupling to std.string is indeed pulling in unwarranted FP support, 
so there is clearly an issue there. Std.string also happens to allocate 
memory for each toString() method (looks like all of them do?). That is 
harldy wise to do at a low level, especially where it can be easily 
avoided. You spelt out some reasons to avoid that yourself, vis-a-vis 
allocation whilst debugging.



> 
>> Looking again at your recital of adamant examples, I'm rather sorry, 
>> and entirely disappointed that's all you got from this exchange.
> 
> 
> I used the word adamant because you haven't acknowledged that I've 
> addressed the underlying __fltused and std.uni issues, you haven't 
> acknowledged that they are solvable compiler issues rather than library 
> design issues, and just keep pushing the same solution.

Sigh


> I shall reiterate that what I was doing was addressing what the 
> underlying issue with coupling was. If those can be successfully 
> addressed, then there is no coupling issue.

I'm very happy you found some problems and were able to rectify them. 
That's great! But that doesn't, in any shape or form, mean there's no 
coupling issues. You think these are the only examples? You feel it's OK 
for std.string to be allocating from the heap, when it can easily be 
avoided instead? That it's cool for low level language-support code 
(like object.d) to be invoking the GC where it could easily be avoided?

I don't. But, I'd be perfectly content if you were to leave it just as it is
April 07, 2006
Re: On processors for D ~ decoupling
Thomas Kuehne wrote:
> Walter Bright schrieb am 2006-04-06:
>> Although there is a lot of code in std.string, unreferenced free 
>> functions in it should be discarded by the linker. A check of the 
>> generated .map file should verify this - it is certainly supposed to 
>> work that way.
> 
> That's not what is happening on Linux:

Hmm. I tried --gc-symbols, which is supposed to do it, but nothing 
happens (even when I try it on C++ files). Can you try --gc-symbols on 
your system?
April 08, 2006
Re: On processors for D ~ decoupling
Walter Bright schrieb am 2006-04-07:
> Thomas Kuehne wrote:
>> Walter Bright schrieb am 2006-04-06:
>>> Although there is a lot of code in std.string, unreferenced free 
>>> functions in it should be discarded by the linker. A check of the 
>>> generated .map file should verify this - it is certainly supposed to 
>>> work that way.
>> 
>> That's not what is happening on Linux:
>
> Hmm. I tried --gc-symbols, which is supposed to do it, but nothing 
> happens (even when I try it on C++ files). Can you try --gc-symbols on 
> your system?

doesn't work: --gc-symbols
seems to work: --gc-sections

Thomas
April 08, 2006
Re: On processors for D ~ decoupling
Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Walter Bright schrieb am 2006-04-07:
>> Thomas Kuehne wrote:
>>> Walter Bright schrieb am 2006-04-06:
>>>> Although there is a lot of code in std.string, unreferenced free 
>>>> functions in it should be discarded by the linker. A check of the 
>>>> generated .map file should verify this - it is certainly supposed to 
>>>> work that way.
>>> That's not what is happening on Linux:
>> Hmm. I tried --gc-symbols, which is supposed to do it, but nothing 
>> happens (even when I try it on C++ files). Can you try --gc-symbols on 
>> your system?
> 
> doesn't work: --gc-symbols
> seems to work: --gc-sections

Right, I typo'd it. However, --gc-sections doesn't work on my system - 
everything is still linked in. But it does on yours - not all of 
std.string is linked in?
April 08, 2006
Re: On processors for D ~ decoupling
Thomas Kuehne wrote:
> Walter Bright schrieb am 2006-04-07:
>> Thomas Kuehne wrote:
>>> Walter Bright schrieb am 2006-04-06:
>>>> Although there is a lot of code in std.string, unreferenced free 
>>>> functions in it should be discarded by the linker. A check of the 
>>>> generated .map file should verify this - it is certainly supposed to 
>>>> work that way.
>>> That's not what is happening on Linux:
>> Hmm. I tried --gc-symbols, which is supposed to do it, but nothing 
>> happens (even when I try it on C++ files). Can you try --gc-symbols on 
>> your system?
> 
> doesn't work: --gc-symbols
> seems to work: --gc-sections

Also, could you post the full, exact command you used? Perhaps I have 
botched that up, too.
April 08, 2006
Re: On processors for D ~ decoupling
Walter Bright schrieb am 2006-04-08:
> Thomas Kuehne wrote:
>> Walter Bright schrieb am 2006-04-07:
>>> Thomas Kuehne wrote:
>>>> Walter Bright schrieb am 2006-04-06:
>>>>> Although there is a lot of code in std.string, unreferenced free
>>>>> functions in it should be discarded by the linker. A check of the
>>>>> generated .map file should verify this - it is certainly supposed to
>>>>> work that way.
>>>> That's not what is happening on Linux:
>>> Hmm. I tried --gc-symbols, which is supposed to do it, but nothing
>>> happens (even when I try it on C++ files). Can you try --gc-symbols on
>>> your system?
>>
>> doesn't work: --gc-symbols
>> seems to work: --gc-sections

> Right, I typo'd it. However, --gc-sections doesn't work on my system -
> everything is still linked in. But it does on yours - not all of
> std.string is linked in?

Correct

> Also, could you post the full, exact command you used? Perhaps I have
> botched that up, too.

$ dmd a.d -ofx
gcc a.o -o x -lphobos -lpthread -lm -Xlinker -L/opt/dmd/dmd/lib
$ dmd a.d -ofy -L--gc-sections
gcc a.o -o y -lphobos -lpthread -lm -Xlinker -L/opt/dmd/dmd/lib -Xlinker --gc-sections
$ ls -sh1 x y
212K x
136K y
$ objdump -t y | awk "{ print (\$4); }" | grep "6string" | sed 's/\.gnu\.linkonce\.t//' | sort -u
_D3std6string3cmpFAaAaZi
_D3std6string4findFAawZi
_D3std6string6columnFAaiZi
_D3std6string7iswhiteFwZi
_D3std6string8toStringFkZAa
_D3std6string9inPatternFwAaZi
$ gcc --version
gcc (GCC) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)
$ ld --version
GNU ld version 2.16.1

Thomas
April 08, 2006
Re: On processors for D ~ decoupling
Thomas Kuehne wrote:
> Walter Bright schrieb am 2006-04-08:
>> Right, I typo'd it. However, --gc-sections doesn't work on my system -
>> everything is still linked in. But it does on yours - not all of
>> std.string is linked in?
> 
> Correct

This is good news. The documentation on --gc-sections is pretty sparse, 
I wasn't sure it was intended to do that, and it does nothing on my system.

> $ ld --version
> GNU ld version 2.16.1

I'm using ld 2.13. The release notes say that --gc-sections works for 
it, but I guess it doesn't actually :-(. Anyhow, it is good news that it 
is working on your system. I'll modify dmd to pass the --gc-sections 
command through to the linker, and I'll not worry about older ld's 
ignoring the switch.

Thanks for helping out with this.
April 08, 2006
Re: On processors for D ~ decoupling
In article <e17um0$1hts$1@digitaldaemon.com>, Walter Bright says...
>
>Thomas Kuehne wrote:
>> Walter Bright schrieb am 2006-04-08:
>>> Right, I typo'd it. However, --gc-sections doesn't work on my system -
>>> everything is still linked in. But it does on yours - not all of
>>> std.string is linked in?
>> 
>> Correct
>
>This is good news. The documentation on --gc-sections is pretty sparse, 
>I wasn't sure it was intended to do that, and it does nothing on my system.
>
>> $ ld --version
>> GNU ld version 2.16.1
>
>I'm using ld 2.13. The release notes say that --gc-sections works for 
>it, but I guess it doesn't actually :-(. Anyhow, it is good news that it 
>is working on your system. I'll modify dmd to pass the --gc-sections 
>command through to the linker, and I'll not worry about older ld's 
>ignoring the switch.
>
>Thanks for helping out with this.

Might want to take a look at the gcc '-s' switch as well. Man page (under gcc
linking options):

-s  Remove all symbol table and relocation information from the executable.

It dramatically reduces the size of the executables on my system. Don't have
much experience with it yet though.

- Dave
April 08, 2006
Re: On processors for D ~ decoupling
Sean Kelly wrote:
> Walter Bright wrote:
>>
>> BTW, internal\dmain2.d also uses printf to print out an error message 
>> relating to any uncaught exceptions.
> 
> Ares currently uses fprintf for this purpose, which is essentially the 
> same thing.  And as you say, it would be easy enough to hook the 
> function if this behavior isn't desirable.
> 
> I'm glad the compiler issues came to light however.  I don't suppose 
> this will have any impact on the template code generation problem in 
> libraries?
> 
> 
> Sean

Sean - could you point me to some links or post some example code on this?

Thanks,

- Dave
April 08, 2006
Re: On processors for D ~ decoupling
Dave wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>>
>>> BTW, internal\dmain2.d also uses printf to print out an error message 
>>> relating to any uncaught exceptions.
>>
>> Ares currently uses fprintf for this purpose, which is essentially the 
>> same thing.  And as you say, it would be easy enough to hook the 
>> function if this behavior isn't desirable.
>>
>> I'm glad the compiler issues came to light however.  I don't suppose 
>> this will have any impact on the template code generation problem in 
>> libraries?
> 
> Sean - could you point me to some links or post some example code on this?

http://svn.dsource.org/projects/ares/trunk/src/dmdrt/dmain2.d

See the "catch" blocks near the end of the file.


Sean
4 5 6 7 8 9
Top | Discussion index | About this forum | D home