On 09/14/2016 12:58 AM, Waldek Hebisch wrote:
> Ralf Hemmecke wrote:
>>
>>>> if % is List(S) then
>>>
>>> You repeat the definition in category, I think repeat the definition
>>> in domain would be better?
>>
>> Certainly better to repeat in List domain. Logically, how would the
>> category know about the actual representation of List. Furthermore,
>> there might be other domains that gain from such repetition and thus
>> inlining. So the domain is a more canonical place if the condition would
>> be "% is ..." instead of "% has ...".
>
> Well, putting definition in category makes it clear that source
> code is identical and repetition is only for performance.
Yes. I agree. In fact, I don't want to see such code duplication at all.
Why I tend more to put duplication into the domain comes from the fact
that I don't want interdependency of the code. And even if "if % is
List(S) then ..." does not need the List domain to compile, compiling
the category, it still anticipates that there will be a domain with name
"List". If I call my own list domain "MyList" I would only benefit from
inlining if MyList is built on top of List.
All this is very List-centric. My comment was more on a general basis.
To make it more clear my preferences are:
No code duplication -- with smart compiler
code duplication in category --- with the goal to remove it via
a smarter compiler
code duplication in respective domain
code duplication in category --- without chance to remove it in
the future by smart compiler
> Actually, one can make actual definition into a macro and
> just invoke it under different conditions, so actual duplication
> of code can be minimized.
Yes. It should certainly be done this way. But it's duplication anyway.
> Spreading out copies in different places makes it harder to notice
> that code is the same. And without comment next year somebody
> notices that we can drop "redundant" definitions.
You say this to the wrong person. I'm always for a good and clear
documentation, even if code duplication happens inside the category.
> Concerning "how would the category know", this is reponsibility
> of bootstrap procedure: during final compilation "core domains"
> (that is domains which may provide operations for inlining)
> are available.
That was not what I "complained" about. I just don't like that the
category depends on a domain, because that looks like adding a
dependency to the code that should logically be invisible. I'd rather
like that the compiler is smart(er) than to put explicit duplicated code
into the source files.
>> The question is whether the compiler should not simply put the inherited
>> the implementation of map! from the category into the domain, but rather
>> "inherit" only the source code and compile again directly for the
>> respective domain, i.e., perhaps inlining some parts. I've no clue
>> whether that would be possible or a desireable behaviour of the compiler.
>
> Possible with more advanced compiler (Aldor is close to this).
> Desirable: yes if done in smat way. Doing such things naively
> may increase size of object code too much.
Yes. Aldor is also not smart enough. I've looked at generated C code and
there were a lot of places that simply inlined print statements and the
respective strings. That made the object code big without any speed
gain. I support your suggestion (in another mail) to profile the code
and train the compiler by the bottleneck list in order to decide which
functions to inline an which not. But I guess that requires good test
examples for the profiling step.
Ralf
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
