Re: [PATCH v4 0/13] Generic Red-Black Trees

[Daniel Santos]

Rob,

Thank you for the education.  I wasn't up on the "anti-tivoization"
issue, but after reading up I would have to say that I'm deeply in that
camp; if I buy the hardware, I should be able to do what I damn well
please with it -- why I haven't purchased an iphone for example.    At
the same time, I also believe in GPL w/link-time exception if the
situation warrants it.  But this is a discussion for another time & place.

On 06/23/2012 11:39 PM, Rob Landley wrote:
> Less optimized but still works with old compilers is fine. (Less
> optimized comes with the territory with old compilers.) 
This was of particular concern to be because of how much less
optimized.  For example, an inline function that expanded to about 128
bytes on gcc 4.6 expanded to 500-ish bytes on gcc 3.4.6.  I guess I
should reserve any further comment until I have hard performance numbers.
> And who's talking "if"?
>
> LLVM/CLANG builds a bootabe linux kernel:
> http://lwn.net/Articles/441018/
>
> Open64 builds a bootable linux kernel:
> http://article.gmane.org/gmane.comp.compilers.open64.devel/2498
>
> The PCC guys make an adorable token effort which is largely ignored:
> http://bsdfund.org/bundle/
>
> Heck, Fabrice bellard did it himself with tinycc back in 2004:
> http://bellard.org/tcc/tccboot.html
Frankly, I'm glad to hear about these endeavors.  I'm not a fan of Apple
because of their business policies, but I'm a huge fan of run-time
optimization being a hard-core Java programmer (and yes, I admit it :). 
I did check out tccboot at one point out of interest.
>> Another question that has to be asked is "Is Linux ready for this?"  The
>> answer today may be "yes" or "no", but to say that it can never be ready
>> is pure folly.
>
> I'm saying that adding complexity is not necessarily an improvement, and
> that over-optimizing at the expense of portability may turn out to be a
> mistake in the long run.
Any time you want to add complexity, it must be justified. However, I'm
operating by the compiler compatibility rules adopted by the Linux
kernel project and putting portability (to non-gcc compilers) as a lower
concern than the 99% use case.
> You keep using the word "paradigm". Voluntarily. I find this odd.
I don't tend to back away from a word just because PHBs (Pointy-Haired
Bosses) like to abuse them.  I'll even use the word "synergistic" when I
think it applies.  What I'm proposing introduces a few new paradigms,
patterns or schools of thought(and I prefer to pronounce it
"pair-uh-dig-uh-me", just because I can).

For one, I'm asking people to use a macro where you leave parameters
empty as a sort of "default" value.  This isn't standard and if I'm
going to ask somebody(especially lots of people) to do something
non-standard I want to make sure I've explored it thoroughly, eliminated
all other options and that there's a really good reason for doing so. 
If I can prove that there's a good reason for doing it, that there are
no other reasonable options, that it has a benefit and is reusable, then
we're using a new paradigm and we have to start thinking about the
interface differently than we're used to thinking about interfaces. 
Many consider this out-right macro abuse -- that is a valid school of
thought.  I'm introducing this as an alternate school of thought.

But the other paradigm that seems to be new is using constant function
pointers for a sort-of "type-injection" for generic inline functions. 
We usually think about function pointers as overhead.  But since gcc's
-findirect-inlining feature has matured, it creates the opportunity for
a new way of thinking about the use of function pointers (when they are
constant) for generic code.  I prefer the term "paradigm" when mechanism
requires a distinct way of thinking about the mechanism and its
components and can be re-used as a pattern.

> So yay standard C99 micro stuff. I'm a little worried about being able
> to unwrap it all and understand what's going on, but unlike templates
> we have cc -E to fall back on here, so ok.
I have (or had) a script somewhere around here to parse that huge
one-line macro out and give it some reasonable linebreaks & indentation
(feeding it gcc -E).  Developing complex pre-processor stuff is a super
pain, so I just want to make sure that using it is as painless as possible.
> Ok, so "designed with gcc 4.6's optimizer in mind, regression tested back to 3.4 for at least minimal functionality, and not intentionally breaking other compilers".
>
> That's what I wanted to know, and it sounds good to me.
Yes.  I wouldn't think it appropriate to propose the patch set if it
degraded performance with a fairly recent compiler (stable).  Although,
gcc 4.6.3 still isn't considered "stable" on Gentoo because there's
still a few (10-ish) broken packages blocking it.

Daniel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/