Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #19569 > unrolled thread

Alternative libraries for C, that are efficient

Back to article view | Back to comp.lang.c

Contents

  Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 09:01 -0700
    Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 09:05 -0700
      Re: Alternative libraries for C, that are efficient ImpalerCore <jadill33@gmail.com> - 2012-04-12 09:38 -0700
        Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:32 -0700
          Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 14:41 -0400
            Re: Alternative libraries for C, that are efficient Willem <willem@toad.stack.nl> - 2012-04-12 18:51 +0000
              Re: Alternative libraries for C, that are efficient nick_keighley_nospam@hotmail.com - 2012-04-13 03:46 -0700
                Re: Alternative libraries for C, that are efficient Willem <willem@toad.stack.nl> - 2012-04-13 14:51 +0000
              Re: Alternative libraries for C, that are efficient Kenneth Brody <kenbrody@spamcop.net> - 2012-04-13 12:38 -0400
                Re: Alternative libraries for C, that are efficient Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-04-15 19:47 +0300
    Re: Alternative libraries for C, that are efficient tom st denis <tom@iahu.ca> - 2012-04-12 09:09 -0700
      Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:13 -0700
        Re: Alternative libraries for C, that are efficient tom st denis <tom@iahu.ca> - 2012-04-12 18:20 -0700
    Re: Alternative libraries for C, that are efficient Jens Gustedt <jens.gustedt@loria.fr> - 2012-04-12 18:13 +0200
      Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 12:47 -0400
      Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:22 -0700
        Re: Alternative libraries for C, that are efficient Jens Gustedt <jens.gustedt@loria.fr> - 2012-04-13 22:37 +0200
          Re: Alternative libraries for C, that are efficient Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-04-15 20:15 +0300
            Re: Alternative libraries for C, that are efficient Jens Gustedt <jens.gustedt@loria.fr> - 2012-04-15 23:30 +0200
    Re: Alternative libraries for C, that are efficient Ben Pfaff <blp@cs.stanford.edu> - 2012-04-12 09:20 -0700
    Re: Alternative libraries for C, that are efficient Noob <root@127.0.0.1> - 2012-04-12 18:34 +0200
      Re: Alternative libraries for C, that are efficient Kaz Kylheku <kaz@kylheku.com> - 2012-04-12 18:00 +0000
        Re: Alternative libraries for C, that are efficient nick_keighley_nospam@hotmail.com - 2012-04-13 03:50 -0700
      Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:24 -0700
        Re: Alternative libraries for C, that are efficient Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-12 13:08 -0700
    Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 12:50 -0400
      Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:30 -0700
        Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 15:55 -0400
    Re: Alternative libraries for C, that are efficient Barry Schwarz <schwarzb@dqel.com> - 2012-04-12 11:41 -0700
      Re: Alternative libraries for C, that are efficient Willem <willem@toad.stack.nl> - 2012-04-12 19:08 +0000
    Re: Alternative libraries for C, that are efficient "BartC" <bc@freeuk.com> - 2012-04-12 21:07 +0100
      Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 20:35 -0400
        Re: Alternative libraries for C, that are efficient "BartC" <bc@freeuk.com> - 2012-04-13 11:38 +0100
          Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-13 09:52 -0400
            Re: Alternative libraries for C, that are efficient "BartC" <bc@freeuk.com> - 2012-04-13 17:56 +0100
        Re: Alternative libraries for C, that are efficient Kenneth Brody <kenbrody@spamcop.net> - 2012-04-13 12:56 -0400
          Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-13 14:48 -0400
            Re: Alternative libraries for C, that are efficient Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-14 07:22 -0700
    Re: Alternative libraries for C, that are efficient Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-04-12 21:23 -0400
      Re: Alternative libraries for C, that are efficient Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2012-04-13 16:52 +0000
    Re: Alternative libraries for C, that are efficient Jens Gustedt <jens.gustedt@loria.fr> - 2012-04-13 23:24 +0200

Page 1 of 3  [1] 2 3  Next page →

#19569 — Alternative libraries for C, that are efficient

Hi,

recently I learned that various "standard C library" functions have
deficiencies in terms of high performance.
Examples include the return values of fgets(), strcpy(), strcat()
(thanks Eric Sosman for mentioning the last 2)

Example:            char * strcat ( char * destination, const char *
source );
Return Value:     destination is returned.

How useless is that! I already know the distination, in the first
place.
Why not return a pointer to the end of the concatenated string, or the
size of the string. This would cost the library no extra performance
cost whatsoever!


Are these deficiencies _only_ string-related?
Is there no good library which I can use for optimal computing?
Because if I use the "standard C library" I'll end up _not_ using many
of it's routines.
Where is a library, that is done right??

Would this library only be a string-handling library, or buffer-
handling library? Or are there other parts of the "standard C library"
that are also deficient.

Surely there must be a good library somewhere, or do all C programmers
really carry their own routines with them?

Thanks.

[toc] | [next] | [standalone]

#19570

> Surely there must be a good library somewhere, or do all C programmers
> really carry their own routines with them?

Or are the deficiencies of the "standard C libary" only an exception;
so that except for a few minor expections, I'll get fabulous
performance from it. So is it actually a really high-performance
library, except for a few minor blemishes.

Or should I really consider C++ and Boost (which is still actively
developed today), with its monstrous features. ;)

[toc] | [prev] | [next] | [standalone]

#19578

On Apr 12, 12:05 pm, John Reye <jonona...@googlemail.com> wrote:
> > Surely there must be a good library somewhere, or do all C programmers
> > really carry their own routines with them?
>
> Or are the deficiencies of the "standard C libary" only an exception;
> so that except for a few minor expections, I'll get fabulous
> performance from it. So is it actually a really high-performance
> library, except for a few minor blemishes.
>
> Or should I really consider C++ and Boost (which is still actively
> developed today), with its monstrous features. ;)

There are many C libraries that specialize on a single task (like
zlib, fftw), and some libraries that try to take a broader approach to
enhance C functionality (GLib).  At the same time, many of these
extensions are scattered about, supported on this subset of OS or
compiler's library, with no centralized location.  Unfortunately,
there is no Boost for C to function as a de-facto repository of these
kinds of functions.

On a different note, performance for performance's sake is not really
useful unless you have something that works.  I place it last on my
software writing priorities.

1. Make it work.
2. Make it pretty. (well designed API, documentation)
3. Make it robust. (handle errors gracefully)
4. Make it fast.   (if you really need to)

Best regards,
John D.

[toc] | [prev] | [next] | [standalone]

#19583

On Apr 12, 6:38 pm, ImpalerCore <jadil...@gmail.com> wrote:
> 1. Make it work.
> 2. Make it pretty. (well designed API, documentation)
> 3. Make it robust. (handle errors gracefully)
> 4. Make it fast.   (if you really need to)

1. Consider what you need: does it need to be fast? is it throw-away-
program? is it part of a large project?
You only need one rule. You cannot generalize, cause it always...
depends. ;)

[toc] | [prev] | [next] | [standalone]

#19585

On 04/12/2012 02:32 PM, John Reye wrote:
> On Apr 12, 6:38 pm, ImpalerCore <jadil...@gmail.com> wrote:
>> 1. Make it work.
>> 2. Make it pretty. (well designed API, documentation)
>> 3. Make it robust. (handle errors gracefully)
>> 4. Make it fast.   (if you really need to)
> 
> 1. Consider what you need: does it need to be fast? is it throw-away-
> program? is it part of a large project?
> You only need one rule. You cannot generalize, cause it always...
> depends. ;)

"Make it work" is always first - if you don't need the program to work
correctly, you don't need to write a new program; there's plenty of
existing programs that already don't do whatever it is that the new
program was supposed to do.

[toc] | [prev] | [next] | [standalone]

#19586

James Kuyper wrote:
) On 04/12/2012 02:32 PM, John Reye wrote:
)> On Apr 12, 6:38 pm, ImpalerCore <jadil...@gmail.com> wrote:
)>> 1. Make it work.
)>> 2. Make it pretty. (well designed API, documentation)
)>> 3. Make it robust. (handle errors gracefully)
)>> 4. Make it fast.   (if you really need to)
)> 
)> 1. Consider what you need: does it need to be fast? is it throw-away-
)> program? is it part of a large project?
)> You only need one rule. You cannot generalize, cause it always...
)> depends. ;)
)
) "Make it work" is always first - if you don't need the program to work
) correctly, you don't need to write a new program; there's plenty of
) existing programs that already don't do whatever it is that the new
) program was supposed to do.

That's the kind of thinking that brought us 2-megabyte XML blobs
as "database entities".  Some stuff you just can't refactor when
it turns out it's a performance killer, so you *have* to account
for that from the beginning.  Not to mention 'if it works, ship'


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#19609

On Thursday, April 12, 2012 7:51:36 PM UTC+1, Willem wrote:
> James Kuyper wrote:
> ) On 04/12/2012 02:32 PM, John Reye wrote:
> )> On Apr 12, 6:38 pm, ImpalerCore <jadil...@gmail.com> wrote:


> )>> 1. Make it work.
> )>> 2. Make it pretty. (well designed API, documentation)
> )>> 3. Make it robust. (handle errors gracefully)
> )>> 4. Make it fast.   (if you really need to)
> )
> ) "Make it work" is always first - 

tho' there are degrees of "work". A fast but inaccurate answer may be better than a "perfectly correct" answer. Sometimes "in good time" is an essential part of the requirement. Your car's anti-lock brakes can't spend hours or minutes deciding the best time to put the brakes on (or take them off).

> ) if you don't need the program to work
> ) correctly, you don't need to write a new program; there's plenty of
> ) existing programs that already don't do whatever it is that the new
> ) program was supposed to do.
> 
> That's the kind of thinking that brought us 2-megabyte XML blobs
> as "database entities".  Some stuff you just can't refactor when
> it turns out it's a performance killer, so you *have* to account
> for that from the beginning.  Not to mention 'if it works, ship'

"don't prematurely optimise" is not an excuse to "prematurely pessimize". Besides if it's been properly designed (see Rule 2) the XML blob will be hidden behind an abstraction and a real database be shoved in with little trouble (I'm aware swopping databases isn't quite as easy as this- but it should be!).

there other things can't be added on afterwards eg. security

[toc] | [prev] | [next] | [standalone]

#19615

nick_keighley_nospam@hotmail.com wrote:
) On Thursday, April 12, 2012 7:51:36 PM UTC+1, Willem wrote:
)> That's the kind of thinking that brought us 2-megabyte XML blobs
)> as "database entities".  Some stuff you just can't refactor when
)> it turns out it's a performance killer, so you *have* to account
)> for that from the beginning.  Not to mention 'if it works, ship'
)
) "don't prematurely optimise" is not an excuse to "prematurely pessimize".

I understand 'pessimize' to be to deliberately make something pessimal.
What I guess you're trying to say is something like: "Do prematurely try
 to get in the right ballpark for optimality."  But that's just a guess.

) Besides if it's been properly designed (see Rule 2) the XML blob will be
) hidden behind an abstraction and a real database be shoved in with little
) trouble (I'm aware swopping databases isn't quite as easy as this- but it
) should be!).

Uh yeah, no.  You see, the 'abstraction' is the source of the problem.
Especially if it's an object oriented abstraction.  OO and databases
really do not mix.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#19618

On 4/12/2012 2:51 PM, Willem wrote:
[...]
> That's the kind of thinking that brought us 2-megabyte XML blobs
> as "database entities".  Some stuff you just can't refactor when
> it turns out it's a performance killer, so you *have* to account
> for that from the beginning.  Not to mention 'if it works, ship'

I thought it was "it compiles without errors... ship it."  :-)

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#19661

Kenneth Brody <kenbrody@spamcop.net> writes:
> On 4/12/2012 2:51 PM, Willem wrote:
> [...]
> > That's the kind of thinking that brought us 2-megabyte XML blobs
> > as "database entities".  Some stuff you just can't refactor when
> > it turns out it's a performance killer, so you *have* to account
> > for that from the beginning.  Not to mention 'if it works, ship'
> 
> I thought it was "it compiles without errors... ship it."  :-)

You've obviously never met our suppliers...

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

[toc] | [prev] | [next] | [standalone]

#19571

On Apr 12, 12:01 pm, John Reye <jonona...@googlemail.com> wrote:
> Hi,
>
> recently I learned that various "standard C library" functions have
> deficiencies in terms of high performance.
> Examples include the return values of fgets(), strcpy(), strcat()
> (thanks Eric Sosman for mentioning the last 2)
>
> Example:            char * strcat ( char * destination, const char *
> source );
> Return Value:     destination is returned.
>
> How useless is that! I already know the distination, in the first
> place.
> Why not return a pointer to the end of the concatenated string, or the
> size of the string. This would cost the library no extra performance
> cost whatsoever!

It's so you can use it in subsequent calls e.g.

puts(strcat(foo, bar));

You could easily write your own mystrcat_end function to do what you
want.

Tom

[toc] | [prev] | [next] | [standalone]

#19579

> It's so you can use it in subsequent calls e.g.
>
> puts(strcat(foo, bar));

I'd rather use
strcat(foo, bar);
puts(foo);

and have a well-designed interface of strcat, to return something
useful.

[toc] | [prev] | [next] | [standalone]

#19599

On Apr 12, 2:13 pm, John Reye <jonona...@googlemail.com> wrote:
> > It's so you can use it in subsequent calls e.g.
>
> > puts(strcat(foo, bar));
>
> I'd rather use
> strcat(foo, bar);
> puts(foo);
>
> and have a well-designed interface of strcat, to return something
> useful.

Nothing stopping you from writing portable replacement functions.  No
need to bitch on USENET about it.

Tom

[toc] | [prev] | [next] | [standalone]

#19572

Am 04/12/2012 06:01 PM, schrieb John Reye:
> recently I learned that various "standard C library" functions have
> deficiencies in terms of high performance.
> Examples include the return values of fgets(), strcpy(), strcat()
> (thanks Eric Sosman for mentioning the last 2)
> 
> Example:            char * strcat ( char * destination, const char *
> source );
> Return Value:     destination is returned.
> 
> How useless is that!

very useful for constructs such as

char const* s = strcat(strcpy(malloc(100), "Hello "), "world");

or

char const* t = strcat((char[100]){ "Hello " }, s);


> I already know the distination, in the first place.

No, not necessarily. The first argument is an expression. This feature
avoids to evaluate that expression multiple times.

Your mileage just varies from that of the C library designers.

Jens

[toc] | [prev] | [next] | [standalone]

#19575

On 04/12/2012 12:13 PM, Jens Gustedt wrote:
> Am 04/12/2012 06:01 PM, schrieb John Reye:
...
>> Examples include the return values of fgets(), strcpy(), strcat()
>> (thanks Eric Sosman for mentioning the last 2)
>>
>> Example:            char * strcat ( char * destination, const char *
>> source );
>> Return Value:     destination is returned.
>>
>> How useless is that!
> 
> very useful for constructs such as
> 
> char const* s = strcat(strcpy(malloc(100), "Hello "), "world");

Using the possibly null value returned by malloc() is not a good idea,
though it is a commonplace bit of lazy programming.

[toc] | [prev] | [next] | [standalone]

#19580

On Apr 12, 6:13 pm, Jens Gustedt <jens.gust...@loria.fr> wrote:
> very useful for constructs such as
>
> char const* s = strcat(strcpy(malloc(100), "Hello "), "world");
What's wrong with:

char * s;
if ((s = (char *)malloc(100)) == NULL) {
  fprintf(stderr, "Out of memory\n");
  exit(1);
}
strcpy(s, "Hello ");
strcat(s, "world");

Are you trying to tell me that your's will be more efficient.
Me'thinks not.


>
> or
>
> char const* t = strcat((char[100]){ "Hello " }, s);
char *t = (char *)((char[100]){ "Hello " });
strcat(t, s);

So the function's interfaces were designed in order to write succint
code, which has absolutely no advantage, if I write it differently???
And as a bonus I cannot use it, when I want to find the end of the
string.

Great. ;)



> > I already know the distination, in the first place.
>
> No, not necessarily. The first argument is an expression. This feature
> avoids to evaluate that expression multiple times.

Sorry, I don't follow. Could you explain it (perhaps with an example).

[toc] | [prev] | [next] | [standalone]

#19624

Hi,

Am 04/12/2012 08:22 PM, schrieb John Reye:
> On Apr 12, 6:13 pm, Jens Gustedt <jens.gust...@loria.fr> wrote:
>> very useful for constructs such as
>>
>> char const* s = strcat(strcpy(malloc(100), "Hello "), "world");
> What's wrong with:
> 
> char * s;
> if ((s = (char *)malloc(100)) == NULL) {
>   fprintf(stderr, "Out of memory\n");
>   exit(1);
> }
> strcpy(s, "Hello ");
> strcat(s, "world");
> 
> Are you trying to tell me that your's will be more efficient.
> Me'thinks not.

Mine is an expression, so it can easily packed in a macro, in the
initializer of a `for`-loop variable, whatever.

>>
>> or
>>
>> char const* t = strcat((char[100]){ "Hello " }, s);
> char *t = (char *)((char[100]){ "Hello " });
> strcat(t, s);

In your's the compound literal makes not much sense, since you give away
the unprotected pointer to it, so it would better be written

char t[100] = { "Hello " };
strcat(t, s);

Mine has the const qualifier on the pointed-to object. How would you
achieve this?

>>> I already know the distination, in the first place.
>>
>> No, not necessarily. The first argument is an expression. This feature
>> avoids to evaluate that expression multiple times.
> 
> Sorry, I don't follow. Could you explain it (perhaps with an example).

If you'd like to use such things in macros (I do) you only want to
evaluate each argument once, because of possible side effects.

#define STRCAT3(X, Y, Z) strcat(strcat((X), (Y)), (Z))

in P99 I have

#define P99_STRCATS(TARG, ...)

that lifts that idea to (almost) any fixed number of arguments.

(Well I am cheating a bit, that one uses stpcpy under the hood to be
more efficient. But the idea is the same.)

Jens

[toc] | [prev] | [next] | [standalone]

#19662

Jens Gustedt <jens.gustedt@loria.fr> writes:
> Hi,
> 
> Am 04/12/2012 08:22 PM, schrieb John Reye:
> > On Apr 12, 6:13 pm, Jens Gustedt <jens.gust...@loria.fr> wrote:
> >> very useful for constructs such as
> >>
> >> char const* s = strcat(strcpy(malloc(100), "Hello "), "world");

gag.

> > What's wrong with:
> > 
> > char * s;
> > if ((s = (char *)malloc(100)) == NULL) {
> >   fprintf(stderr, "Out of memory\n");
> >   exit(1);
> > }
> > strcpy(s, "Hello ");
> > strcat(s, "world");
> > 
> > Are you trying to tell me that your's will be more efficient.
> > Me'thinks not.
> 
> Mine is an expression, so it can easily packed in a macro, in the
> initializer of a `for`-loop variable, whatever.
> 
> >>
> >> or
> >>
> >> char const* t = strcat((char[100]){ "Hello " }, s);
> > char *t = (char *)((char[100]){ "Hello " });
> > strcat(t, s);
> 
> In your's the compound literal makes not much sense, since you give away
> the unprotected pointer to it, so it would better be written
> 
> char t[100] = { "Hello " };
> strcat(t, s);
> 
> Mine has the const qualifier on the pointed-to object. How would you
> achieve this?
> 
> >>> I already know the distination, in the first place.
> >>
> >> No, not necessarily. The first argument is an expression. This feature
> >> avoids to evaluate that expression multiple times.
> > 
> > Sorry, I don't follow. Could you explain it (perhaps with an example).
> 
> If you'd like to use such things in macros (I do) you only want to
> evaluate each argument once, because of possible side effects.
> 
> #define STRCAT3(X, Y, Z) strcat(strcat((X), (Y)), (Z))

retch.

> in P99 I have
> 
> #define P99_STRCATS(TARG, ...)
> 
> that lifts that idea to (almost) any fixed number of arguments.
> 
> (Well I am cheating a bit, that one uses stpcpy under the hood to be
> more efficient. But the idea is the same.)

How can you use the word "efficient" so close to code that,
from an efficiency viewpoint, is so obviously inefficient?
Do you have an efficient bubblesort too in your library?

If you want to concatenate 3 strings, using sprintf should be
way more efficient than the above nonsense.

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

[toc] | [prev] | [next] | [standalone]

#19665

Am 04/15/2012 07:15 PM, schrieb Phil Carmody:
> 
> gag.
> 
> retch.
> 
> nonsense.

blub

[toc] | [prev] | [next] | [standalone]

#19573

John Reye <jononanon@googlemail.com> writes:

> Example:            char * strcat ( char * destination, const char *
> source );
> Return Value:     destination is returned.
>
> How useless is that! I already know the distination, in the first
> place.
> Why not return a pointer to the end of the concatenated string, or the
> size of the string. This would cost the library no extra performance
> cost whatsoever!

SUSv4 has stpcpy() that does just that.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web