Re: Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))

2000-12-20 Thread David O'Brien
On Wed, Dec 20, 2000 at 11:03:48AM +1030, Greg Lehey wrote: On Tuesday, 19 December 2000 at 16:01:52 -0800, David O'Brien wrote: On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote: /* Case 1 */ /* Case 2 */ if (data) vs.

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-19 Thread David O'Brien
On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote: /* Case 1 */ /* Case 2 */ if (data) vs. free(data) free(data); Actually from an optimization standpoint, #1 can be worse (ie, harder on the processor).

Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))

2000-12-19 Thread Greg Lehey
On Tuesday, 19 December 2000 at 16:01:52 -0800, David O'Brien wrote: On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote: /* Case 1 */ /* Case 2 */ if (data) vs. free(data) free(data); Actually from an

Re: Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))

2000-12-19 Thread Peter Seebach
In message [EMAIL PROTECTED], Greg Lehey writes: In which processors is a function call anywhere near as cheap as a conditional local branch? Doesn't PPC have some cases where a leaf function is basically free? -s To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe

Re: Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))

2000-12-19 Thread Luigi Rizzo
On Tuesday, 19 December 2000 at 16:01:52 -0800, David O'Brien wrote: On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote: /* Case 1 */ /* Case 2 */ if (data) vs. free(data) free(data); Actually

Re: Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))

2000-12-19 Thread Matt Dillon
Guys, on intel a simple conditional is going to be a whole lot expensive then a subroutine call no matter what, even if the conditional misses. Subroutine calls are very fast on a P6, but if they push anything on the stack at all beyond the return address they are not going

Re: Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))

2000-12-19 Thread Matt Dillon
:Guys, on intel a simple conditional is going to be a whole lot :expensive then a subroutine call no matter what, even if the I'm really batting 0 today on grammer. I of course meant... "whole lot LESS expensive". :-) -Matt To

Re: Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))

2000-12-19 Thread Jacques A. Vidrine
On Tue, Dec 19, 2000 at 06:36:06PM -0600, Peter Seebach wrote: In message [EMAIL PROTECTED], Greg Lehey writes: In which processors is a function call anywhere near as cheap as a conditional local branch? Doesn't PPC have some cases where a leaf function is basically free? Maybe, but

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-19 Thread Jacques A. Vidrine
On Tue, Dec 19, 2000 at 04:01:52PM -0800, David O'Brien wrote: On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote: /* Case 1 */ /* Case 2 */ if (data) vs. free(data) free(data); Actually from an

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-18 Thread Jacques A. Vidrine
On Sun, Dec 17, 2000 at 10:01:58PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : I hate to give up a line for : : if (data) : free(data); : : but neither do I care for ``if (data) free(data);''. I guess if I : were writing

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-18 Thread Warner Losh
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : None taken. It is however a simple and safe optimization, with no : apparent downsides. It has the same attraction as using bit shifts : instead of multiplication/division, or saving the value from a function : call that will be needed

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-18 Thread Matt Dillon
:: None taken. It is however a simple and safe optimization, with no :: apparent downsides. It has the same attraction as using bit shifts :: instead of multiplication/division, or saving the value from a function :: call that will be needed again later, even if you know the function call :: is

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-18 Thread Jack Rusher
"Jacques A. Vidrine" wrote: I doubt that you could measure any difference between if (foo) free(foo); and free(foo); Nevertheless, I tend to write it that way at times -- maybe because it seems so natural to me to ask `do I need to free this thing?' -- and that gets translated

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-18 Thread Jacques A. Vidrine
On Mon, Dec 18, 2000 at 11:40:43AM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : None taken. It is however a simple and safe optimization, with no : apparent downsides. It has the same attraction as using bit shifts : instead of

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-18 Thread Warner Losh
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : Ever notice that you tend to send more email when you should be studying : for a final? That's why Style(9) wars break out this time of year. :-) : /* Case 1 */ /* Case 2 */ : if (data)

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-18 Thread Drew Eckhardt
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: /* Case 1 */ /* Case 2 */ if (data) vs. free(data) free(data); I don't see that Case 1 obfuscates anything. In some cases I find it clearer: Case 1 implies that

Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-17 Thread Jacques A. Vidrine
[This typo came from NetBSD, so in this particular source I have no intention of changing the style.] What do folks think about 1)if (data) free(data); versus 2)free(data); versus 3)#define xfree(x) if ((x) != NULL) free(x); xfree(data); --

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-17 Thread Bosko Milekic
On Sun, 17 Dec 2000, Chris Costello wrote: On Sunday, December 17, 2000, Jacques A. Vidrine wrote: What do folks think about 1)if (data) free(data); versus 2)free(data); versus 3)#define xfree(x) if ((x) != NULL) free(x);

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-17 Thread Jacques A. Vidrine
On Sun, Dec 17, 2000 at 03:17:35PM -0600, Chris Costello wrote: 2. The C standard dictates that free() does nothing when it gets a NULL argument. Well, it dictates that free(NULL) is safe -- it doesn't dictate that it ``does nothing''. Which brings me to my next comment: The other

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-17 Thread Jacques A. Vidrine
On Sun, Dec 17, 2000 at 03:36:56PM -0600, Chris Costello wrote: On Sunday, December 17, 2000, Jacques A. Vidrine wrote: It would be silly to optimize for freeing NULL pointers. You mean as seen in: [snip ifree(), which checks for a NULL pointer, first thing] called by free():

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-17 Thread Jacques A. Vidrine
On Sun, Dec 17, 2000 at 04:04:42PM -0600, Chris Costello wrote: On Sunday, December 17, 2000, Jacques A. Vidrine wrote: I may have missed your point ... or maybe you are just agreeing with what I wrote. For this particular implementation of free, you get the following for `free(foo)'

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-17 Thread assar
"Jacques A. Vidrine" [EMAIL PROTECTED] writes: What do folks think about 1)if (data) free(data); versus 2)free(data); versus 3)#define xfree(x) if ((x) != NULL) free(x); xfree(data); (2), unless you can show that you actually win

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-17 Thread Warner Losh
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : What do folks think about : : 1)if (data) : free(data); : : versus : : 2)free(data); : : versus : : 3)#define xfree(x) if ((x) != NULL) free(x); : xfree(data); Number 2. ANSI-C (aka c89)

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-17 Thread Warner Losh
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : I hate to give up a line for : : if (data) : free(data); : : but neither do I care for ``if (data) free(data);''. I guess if I : were writing several statements like that in a single file, I would : consider the

Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)

2000-12-17 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Warner Losh writes: Number 2. ANSI-C (aka c89) requires that free(NULL) work. We shouldn't go out of our way to pander to those machines where it doesn't. The reason why this is so is that it is legal for realloc(ptr, 0): to return either a NULL pointer