I
Ian Collins
Which is why container libraries are so useful. Your point was?
Which is why container libraries are so useful. Your point was?
J
jacob navia
Seebs a écrit :
They are already loaded into RAM, but not into the processor caches.
Ram is MUCH slower than the processor.
Processor clocks at 2-3GHZ, and RAM access is at around 300MHZ or
around 10 times slower. Any access to RAM provokes "wait states"
where the processor idles until the RAM is ready.
A smaller program will be faster than a big program because it could
fit into the processor cache entirely or to a great extent.
Inline provokes code bloat, and less of the program will fit the cache.
RAM access to read the code into the cache will slow down everything.
They are already loaded into RAM, but not into the processor caches.
Ram is MUCH slower than the processor.
Processor clocks at 2-3GHZ, and RAM access is at around 300MHZ or
around 10 times slower. Any access to RAM provokes "wait states"
where the processor idles until the RAM is ready.
A smaller program will be faster than a big program because it could
fit into the processor cache entirely or to a great extent.
Inline provokes code bloat, and less of the program will fit the cache.
RAM access to read the code into the cache will slow down everything.
J
jacob navia
Richard Heathfield a écrit :
silent
Thanks Mr Heathfield, I appreciate your message.
jacob
Well, I suspected that, but I did not want to stay
silent
Thanks Mr Heathfield, I appreciate your message.
jacob
S
Sebastian
That's a little one-sided, don't you think? Isn't it true that
"inline" is just a hint for the compiler? I would expect GCC -- when
used with option -Os -- to inline only when pushing arguments and a
return adcress onto the stack, saving registers, invoking the function
(etc) is likely to have a similar code size than the actual code from
the function when inlined. When I think of inlining in the context of C
++ libraries I have things like the following in mind:
class some_list_iterator
{
node *ptr;
public:
...
list_iterator& operator++() {ptr = ptr->next; return *this;}
list_iterator& operator--() {ptr = ptr->prev; return *this;}
data_type& operator*() const {return ptr->data;}
};
or
class string
{
char *beg_, *end_, *capacity_;
public:
...
int size() const {return end_ - begin_;}
char& operator[](int index) {return beg_[index];}
};
Here, the functions are implicitly "inline" (but not necessarily
inlined) due to the fact that their definition is inside of a class
definition. I expect inlining to improve performance in these cases --
in terms of speed *and* memory requirements -- while retaining
encapsulation. A good C++ compiler would probably inline these very
short functions and avoid creating separate function symbols for it.
The nice thing is that optimization can work across function call
boundaries when they're inlined.
On the other hand, you seem to be forcing a kind of dynamic
polymorphism onto users which is not be needed in every case. For
example, if I create a linked list and want to iterate over it and I
*know* it is a list (of, say, floats), I still have use the GetNext
function pointer that is stored in the iterator object or just use
smelly code to access dlist_element::Next directly myself. I would
call this an "abstraction penalty" which is (from what I can tell) a
little harder to avoid in C.
Cheers!
SG
I
ImpalerCore
I don't believe that most people care that much about library code
size. I know I certainly don't; it's not a strong selling point. RAM/
CPU cache is cheap, development/testing time is much more expensive.
What's more important is presenting the interface in a way that
appeals to people that inspires them to try it out. Remember, most C
developers have their own pet container library that they use or just
build data structures from scratch. Trying out a new library is time
intensive and potentially risky, and it's difficult to get people to
switch from what they are comfortable with. You can make the
transition for other people easier, at the cost of a *lot* more work
on the developer end.
1. Implement a form of systematic code documentation. Man pages or
doxygen generated docs and the like are popular, but they are useful.
It's a much more convenient interface to explore a library's API than
looking up information in a word document.
2. Code examples of every API function, preferably those that
demonstrate the caveats and proper techniques of using the library.
In my opinion, the easiest way for people to adapt to a new library is
through coding by example. This requires even more work than simple
doxygen-like API code documentation.
3. Develop a unit testing framework to validate your library. This
helps new users that switch to your library to have some warm fuzzy
feeling that your library isn't buggy and going to make their lives
harder than using their own pet container library. Their pet library
may have problems of its own, but usually they are familiar with
them. If other developers are motivated to join the project, having
this in place will be of great help. Of course building a unit test
framework is a huge project all by itself.
4. Have some kind of useful (hopefully popular) open source project
or framework that depends on your library. This gives more people
confidence that something cool can be done with your library.
I realize that this is a ridiculous amount of work, but I believe that
this is the minimum bar that is needed for the C committee to even
*consider* a standard C container library if you're serious in
pursuing that goal. The bar is likely much higher, as in getting
Boost like popularity. At least there is evidence on the C++ side
that stuff in Boost has actually got the C++ committee's attention.
And even then there's the risk that it may not come to fruition, as
you have to deal with history and politics. But at the same time,
it's never going to ever get done unless someone gives it a try.
While I'm motivated to look at your library documentation and source
code from my own curiosity, what's presented isn't enough to motivate
me to replace what I've been using yet. The code size advantage is
not a wow factor that's enough to motivate me to take the risk to
develop with or convert to your library.
I do thank you for showing a different perspective on building a C
container library and will keep an eye on further developments.
Best regards,
John D.
L
lawrence.jones
In comp.std.c Richard Heathfield said:
NOBODY expects the League of Container Developers!
M
Malcolm McLean
It's why good continaer libraries are useful, and bad or non-
standardised ones are problematic.
Most of your functions will accept lists and return lists. If it is
not easy to do so, then everything becomes difficult. The usual C way
of doing it is to pass a pointer to the list together with a length
parameter. This isn't ideal (it becomes messy when the list can be of
arbitrary data types, or any numeric data type), but it works
reasonably well. A container library has got to work better.
R
Rob Kendrick
NOBODY expects the League of Container Developers![/QUOTE]
But do they have a comfy chair? I'm in need of one.
B.
S
Seebs
AMONG our chief weapons are surprise, wide portability, O(log(N))
efficiency, well-considered design tradeoffs, and excellent documentation.
-s
I
Ian Collins
That is a very naive over simplification. There are many cases where
inline will reduce code size and improve cache and more importantly,
register and use. For example small functions or larger ones with many
parameters. That is why compilers have their own rules for determining
which functions should be inlined ans which should not.
E
Ed
Nick said:
Those who have a distaste for template machinery. Those who are not
large-scale developers. Those who are not compiler vendors. Those who
value simple elegance over ultra-generality. Those who want to understand
the code of the libraries they use. Those who have the capability to
create and build things rather than just using things that others have
created/built ... Others. Standards are those things that are
one-size-fits-all things and one-size-fits-all is fantasy (or politics).
I was not the one who coined the phrase that once something is
"standardized" that it is effectively dead. Standards are for compiler
vendors, and the more complex, the better, for it is a cash cow. (I bit,
but only a bit, facetious). YMMV.
I really don't care what cowboy coders do. It's ashame when they waste
other peoples' time and don't respect other peoples' time. There are
those who simply can't learn from others and history and must learn
everything directly. Then again, there are those who are not as oblivious
as they seem to be and rather have hidden and/or personal agenda.
You heard it here first folks! (Answer: relatively so, yes). Consider,
"porting" existing C code to another language vs. doing the same with
existing C++ code. The former is much more doable while the latter is
nearly impossible and closer to an entire rewrite. That should be clearly
obvious. Of course, it doesn't have to be as difficult as it is, but
because C++ is so idiosynchratic, it is much worse than it has to be.
Consider that much of C++'s longevity will be because of the lock-in
factor rather than because of it's inherent merit. When a new language
comes along that offers decided benefits, the C++ lock-in factor will
probably preclude one from taking advantage of it.
Surely you jest! Certainly a quick google will find you enough material
to realize it is inadequate, especially for a standard which values first
and foremost to be all-things-to-all-people as far as generality goes.
It's idiosynchratic and is at the lowest (almost) level of code and
should be enough to stop projects in their tracks until they create some
suitable replacement (and surely some do just that).
Then you are not very observant.
It was a "car analogy" (engines actually: the horsepower-torque
tradeoff). Don't worry about it. The thing I was trying to point out is
that most always there is a tradeoff in one area for a gain in another.
I
ImpalerCore
I wanted to isolate this one because I do think that this is probably
the strongest side-effect/deficiency of "standardization". I fear
that the next generation of programmers (and I'm one of them) may lack
the 'under-the-hood' understanding because of the increasing
encapsulation found in programming languages. For example, I haven't
programmed very little assembly, and it's obvious that it does hurt my
understanding of concepts described by some of the veterans here.
Okay, you seem to have a habit at looking at the issue with the glass
half-empty, or maybe 3/4 empty. Sorry, but history has shown that the
concept of having a standard in general simplifies issues rather than
complicates them. Maybe you'd like to read scientific papers where
each country uses their own measurement system ... *cough* USA
*cough*. Perhaps you'd prefer to go back to the neapolitan age of
UNIX. Perhaps you'd enjoy crossing state lines and switching from
driving on the left and the right lanes of the road.
The largest benefit of code standardization is not in the content of
the standard itself, but as a common communication language between
developers and users. Pretend there is no C standard library. How
many different names and versions of 'strlen' would be out there? In
the end, you'd probably write it from scratch every time, and everyone
other "you" would do the same. What a standard buys you is that you
or I can look at the strlen function and have an intuitive
understanding of what it's supposed to do. It may not be what you
want all the time, but if a sufficiently large enough number of people
can agree on it, I believe it's worth the effort.
It seems that you and the early C++ proponents would disagree that the
STL is a good thing, and that's fine. People like you were in the
minority when C++ was being standardized, and the committee voted it
in. I'd rather live by a democracy of the many than a dictatorship of
the few. However, in contrast with some of the attitude displayed
here, I prefer to hear your voice of dissent even if I don't agree
with it.
I'm sorry, but are you the sheriff of this here parts? Show me the
badge.
That's a flaw of all humans in some form or another.
Again, another human flaw. Just keep in mind that its the flaws that
keep life interesting.
I think you have a point here, and I pretty well agree with it. It's
the exact same problem with trying to get a standard C container
library adopted. For example, Navia may come out with a superior
library to what I'm using, but because I've been using what I've got
for so long, it's much harder to wrestle me away to use something
else. I don't see the problem going away anytime soon.
No, I believe the intent is that it supposes to be a good-thing-for-
most-people.
Perhaps, but I have no idea how pervasive that issue is. Maybe you've
had a string of bad luck with it.
Let me ask you a question if you don't mind. Do you think the
standardization of the C library portion as given in the standard in
1989 was overall a mistake?
Best regards,
John D.
J
jacob navia
Ian Collins a écrit :
Obvious. There are *some* cases like that. For instance lcc-win inlines
strlen to less bytes than the call instruction and associated push/pop
of the stack frames.
But the generated tight loop is surely not as fast for long strings as
the library strlen is... I betted that most strings are short. With
long strings, it is better to read a register full of characters
and with some shifts determine if there is a zero. I posted the code
in this group: it was called "Knuth's strlen". That code is much
bigger since you have to align at the start and the end of the
string to a 4 byte boundary, etc.
Obviously for VERY simple functions this would be a win but those
cases are rare in C. Since there are no classes, functions that
just access a data member are rare too.
In a nutshell: Yes, inlinen *can* b good in *some* cases but in
GENERAL it is a bad idea.
Functions with a lot of parameters tend to be quite big.
That is why compilers have their own rules for determining
Maybe, but they are surely not very clever...
Obvious. There are *some* cases like that. For instance lcc-win inlines
strlen to less bytes than the call instruction and associated push/pop
of the stack frames.
But the generated tight loop is surely not as fast for long strings as
the library strlen is... I betted that most strings are short. With
long strings, it is better to read a register full of characters
and with some shifts determine if there is a zero. I posted the code
in this group: it was called "Knuth's strlen". That code is much
bigger since you have to align at the start and the end of the
string to a 4 byte boundary, etc.
Obviously for VERY simple functions this would be a win but those
cases are rare in C. Since there are no classes, functions that
just access a data member are rare too.
In a nutshell: Yes, inlinen *can* b good in *some* cases but in
GENERAL it is a bad idea.
Functions with a lot of parameters tend to be quite big.
That is why compilers have their own rules for determining
Maybe, but they are surely not very clever...
N
Nick Keighley
I suspect how its how you do your counting. I'll admit its high but
95% sounds way too high
nonsense. Many of my functions accept and return lists but no way most
of them.
95% sounds way too high
nonsense. Many of my functions accept and return lists but no way most
of them.
I
Ian Collins
Not in My C. I use a lot of small functions, knowing most of them will
end up in line.
No, it isn't. Well OK, it is if the compiler isn't very smart, but
decent compilers make better choices.
You'd be surprised. A lot of development effort is spent on improving
inline selection heuristics. Add in profile feedback and you can get
very good results.
I
Ian Collins
Not mine. If they do, they don't accept lists by value.
Well it is simple, probably marginally simpler in C++ than in C.
Returning list is also made easy with a useful compiler trick known as
return value optimisation.
Which implies some form language support for generics or dynamic types.
Jacob's approach uses dynamic binding, which is the best compromise in C.
N
Nick Keighley
I'll apply ruthless snipping here as you are becoming tedious
I've no idea what that means.
STL code is widely available. I think you have a bit of NIH syndrome.
Those who have the capability to
more NIH. I can build linked lists but why bother when there is a high
quality generalised implementaion available. Do you write every line
of code yourself? Do you write the compiler?
Do you design your own language? Why are you posting here then?
no. If civil engineers thought like you every nut and bolt would be
hand forged.
standards are for everyone. I only see so far because I stand on the
shoulders of giants.
I do. They waste time by reinventing square wheels. The re-implement
linked lists on every project. Badly.
me too
you seem to be one of 'em
this is because C does very little for you. C's functionality is
duplicated in many other languages. Try porting Python or Common Lisp
or smalltalk to another language or pardigm.
than those other languages?
could you give an examples? What would I google for?
this directly contrdicts my experience
you have come up with nothing.
and I don't see it. What is wrong with std::string and std::vector for
small projects? Why can't you answer a simple question?
I've no idea what that means.
STL code is widely available. I think you have a bit of NIH syndrome.
Those who have the capability to
more NIH. I can build linked lists but why bother when there is a high
quality generalised implementaion available. Do you write every line
of code yourself? Do you write the compiler?
Do you design your own language? Why are you posting here then?
no. If civil engineers thought like you every nut and bolt would be
hand forged.
standards are for everyone. I only see so far because I stand on the
shoulders of giants.
I do. They waste time by reinventing square wheels. The re-implement
linked lists on every project. Badly.
me too
you seem to be one of 'em
this is because C does very little for you. C's functionality is
duplicated in many other languages. Try porting Python or Common Lisp
or smalltalk to another language or pardigm.
than those other languages?
could you give an examples? What would I google for?
this directly contrdicts my experience
you have come up with nothing.
and I don't see it. What is wrong with std::string and std::vector for
small projects? Why can't you answer a simple question?
I
Ian Collins
Because he's trolling you!
E
Ed
ImpalerCore said:
It's my job to focus on problems and solutions. If everything is A-OK,
then I have to go looking for something else to do. When the tools are
the problem though, then it's a BIG problem.
Generalizations are pretty much useless. But in the context of the
discussion, there can be had facts about language library standards:
Initially they can be good because the "get everyone on the same page"
and thereby enable integration. Everyone doesn't need that though and it
is a very fine-grained focus. A problem is that they are usually
"one-size-fits-all" or not good to begin with or just plainly and simply
the wrong thing (to be found out later maybe). As it becomes more
entrenched, it hangs around too long and because of that progress is
stifled (example: std::string in C++). A standard library, if taken as
"the last word", is like saying that the a dump truck (gotta meet
large-scale requirements remember) should be the standard vehicle that
everyone should drive. It's silly to think that "one-size" can "fit all".
That is but one thing amongst many. Some may not need that and would be
better served by having more choices. Knowing how these things change,
the above "requirement" is rather short-term focused (unless one is being
grandiose). I didn't put the standards there, but it would be interesting
to know what those who did think now (if you could get them to actually
tell you instead of just politicing which is another thing entirely).
Surely we would have had the right thing by now if there wasn't a
standard C library, IMO. That everyone else is jumping off of a cliff
does not make it a good idea to jump also. That there is a "standard"
library, doesn't mean, of course, that someone/team has to use it. That
choice probably needs more consideration. I think it's a no-brainer to
rethink everything all the time and I am more long-term focused than just
getting something going that works. "Slow and steady...", lol.
Why would someone write it from scratch if they built it already for the
last project? Adapt it and evolve it probably, but the major work was
done on the last project.
2 things. Standardization that happens to early is like putting source
code into the control system for all the team to hack on/at before it is
time to do so. Secondly, reviews and improvement and just plain ol
replacement doesn't happen often enough. But that's what they mean by a
standard language being dead (I did not coin that).
I'm not debating "standards", just the "one and only" mantra, and THAT is
what most people mean by it. Standard at the language proper level OK, at
least not as bad as at the library level. I was evolving a library for
C++ when Rogue Wave's Tools.h++ came out and that stopped me from
pursuing my own library further. Big mistake, in retrospect. STL and the
standard library probably killed off other Roque Wave-like companies and
therefor that further engineering never happened.
It surely has its place. At its age now, probably only a place in
history. (RIP!
).It's definitely a clique.
It's always easier just to follow (until the lead sheep jumps off the
cliff).
I am not dissenting. The key is that if it's not worth doing right, then
it's not worth doing IMO.
Ha ha.
Somehow I get the impression that programmers are most afflicted. (That
was a joke).
Rather, it suppress, represses, oppresses. I don't find that
"interesting" at all.
This whole fascination with "there can only be and must only be one"
escapes me. "it slices! it dices! it removes warts!". Eww!
Appointed/annointed/blah-blah. It's a library. Build it, market it and
sell it. If no one buys it, it's crap or no one wants or needs it. Of
course if there was cost involved, THEN there WOULD be viability
research, etc. Put it up on SourceForge or somewhere if you think that
jumping right into to code on a whim is professional. I think it is very
Un.
A long time ago (before C++), was the time to solicit submissions for C.
That time has passed IMO. A C library in C style could be had pretty
easily. Doing the OO thing with C is useless IMO, surely not within the
domain of a C standard library, but what do I know. I'm just a lurker.
Close enough to what I said.
Punny (rhymes with "funny"). It's just obsolete (and it was never the
right thing anyway, but maybe it's an inherent design fault in the
languages lower foundation, surely). Here we have a perfect example of
why a standard library is bad.
"mistake" is the wrong word. It's not their fault, they didn't know any
better. Did it happen too soon? Did it stay too long? Probably yes on
those 2 questions, I wasn't there so I don't know what the existing and
potential user base was at the time. Same as I don't know what it is
today and would not embark on such a thing without first finding that out
and other things. My incling says that there is a user group that may
want something, but to put it in the standard, I think that is probably
worse today then back then because there are so many more ways to skin
the proverbial cat so there is no way to dictate a standard, or at least
it's oxymoronish for it would only serve a segment of the user base (I'm
hypothesizing). But again, that can be determined a priori so why not go
about it diligently. If it's worth doing, it's worth doing right. If I
thought I could build the bestest library ever for C and it was a "sure
thing", I would make it and put a price tag on it. Now if I wasn't
confident enough that there wasn't low enough risk, I would investigate
that rather than just trying to spread around the risk inherent to sloppy
project planning. (Not that I'm a nice guy or anything though).
I probably shouldn't post when it's past my bedtime, but yaz seem like a
spirited bunch who like each other, so what the heck. Maybe some of it is
coherent. LOL. Goodnight. Have fun.
B
BGB / cr88192
Moi said:
yeah...
the problem with containers tends to be:
general-purpose containers are easy enough to write, and probably most
non-trivial apps have done so;
to really be "good", a container ends up needing to be fairly specialized to
the particular types and usage domain it is being used with.
yes, one can easily enough implement a generic container format, and try
using it for nearly everything, but then the problem is that it may start
eating performance, as well as the more subtle cost of creating internal
dependencies. this leads to, for many tasks, writing task-specialized code.
about the only real generic container that works well in C is arrays, but
arrays as well have obvious limitations.
a few comments:
for many of my libs, internal use of "Object->VTable->Method" style
constructions have usually been wrapped, such as:
FCL_API void fclAdd(fclContainer *cont, fclObject *item)
{ cont->vtable->Add(cont, item); }
which in some cases have in-turn been passed in interface structures (mostly
for sake of "soft linking" against an API).
my reasoning is mostly that this abstracts the client code from knowing what
is going on inside an object (especially since some of my API's may involve
a fair amount of internal hackery which may otherwise obscure such a simple
interface).
similarly, it makes a nice C-friendly API. admitted, these sorts of
indirections are not free (especially since many typical C compilers don't
know how to optimize tail-calls...).
granted, in my main (dynamic) typesystem, it is actually needed to use an
API call to fetch the object vtable for many operations where the object
type is unknown (such as 'dyToString(obj)'...), given a few internal edge
cases:
non-memory objects, pointers outside GC heap, pointers not at object base,
....
but, many APIs are more specialized, and so directly access vtables (and my
GC has an API call of more quickly fetching the main vtable if one is
certain the object is on-heap and that the pointer is to the object base,
but this case rarely comes up).
it may also be possible to register manually-managed memory (via malloc or
mmap / VirtualAlloc) with the typesystem (via callbacks), where there is no
particular restriction on memory layout (I have typically used it with raw
arrays of structs and similar). technically this is the slowest case at
present.
note: there is an internal conflict in my projects between use of dynamic
typing, and use of raw types (base types, structs, ...) and reflection
facilities, although there is some overlap in the internals...
but, yeah, a lot of this is unlikely to apply in Jacob's case...
misc:
is "$(TYPE)" some kind of macro-based generics-facility or similar?...
or, is it more just an alternative notation for something like:
foo_##TYPE##_bar
or similar?...
but, yeah, I expect containers to end up in the standard about as much as I
can expect GC, a dynamic type system, or OO facilities...
both can be used easily enough as library features though.
(some idle thinking wandering off into the land of how to best handle
C#/Java style interface mechanics in C land, but I decided not to go into
this here...).
I suspect, at best, they are likely to end up as "platform APIs", where one
builds a platform "above and beyond" plain C, examples:
Win32 or POSIX APIs (these being OS-specific, but known present on the OS);
GNome and similar (known present when developing GNome apps on Linux, and
almost entirely non-present otherwise...);
....
so, it is a matter of a certain platform being available, which is, granted,
a sort of all-or-nothing proposition in some ways (although, granted, it
would be better if more of these were themselves, at least internally,
standardized, rather than the more common annoyance known as "the
implementation IS the standard...").
sadly, I also dislike monoliths, but in some ways, a platform is inherently
a monolith...
or such...