Re: sorting the input

**Hendrik Schober** · Sep 24 '08, 02:15 PM

Re: sorting the input

Jorgen Grahn wrote:

On Fri, 19 Sep 2008 13:30:52 -0700 (PDT), James Kanze <james.kanze@gm ail.comwrote:

>On Sep 19, 12:55 pm, Jorgen Grahn <grahn+n...@sni pabacken.sewrot e:

>>On Wed, 10 Sep 2008 17:06:16 +0500, arnuld <sunr...@invali d.addresswrote:

....

>>> std::cout << "--------------------------------"
>>> << std::endl;
>>I would skip the std::endl here though, and use "...---\n" instead.

>Sounds like premature optimization to me.

>
No, it's more "do not do things without a reason" or "use the simplest
construct which does what I want".
>

>>std::endl is not "the thing you should use instead of '\n'"
>>(although many people believe it is, for some reason).

>Just the opposite. Most of the time, std::endl is preferable.
>With '\n', you never know when your data is going to end up on
>disk.

>
My reasoning is the opposite of yours. Most of the time I don't care
when the data hits disk[1], and I make this clearer by not using
std::endl.
>
(OK, I admit I also have this suspicion -- not confirmed by
experiments -- that std::endl means a large performance hit in some
situations. I don't want my Unix pipelines to run at half the speed
because there is extensive I/O flushing somewhere along the way.)
>
I thought everyone reasoned like that about endl, except newbies who
used it because they thought that '\n' was somehow a less portable way
of ending a line. But I know you as an experienced and careful C++
programmer, so I clearly have to revise that opinion ...

For me it's very likely also the first time I disagree with James.
I have seen someone debugging and profiling an application for a
week to no avail, until he was told to replace 'std::endl' by '\n',
which made the code he was trying to speed up (which wrote big files)
ten times faster and ended all his performance woes.
I've been hammering "use '\n' unless you /want/ to flush" into quiet
a few generations of students since...

/Jorgen
>
[1] Or whatever endl guarantees on my system; I assume it will at
least leave the application.
>

Schobi

**James Kanze** · Sep 24 '08, 03:35 PM

Re: sorting the input

On Sep 24, 12:31 pm, Jorgen Grahn <grahn+n...@sni pabacken.sewrot e:

On Fri, 19 Sep 2008 13:30:52 -0700 (PDT), James Kanze
<james.ka...@gm ail.comwrote:

On Sep 19, 12:55 pm, Jorgen Grahn <grahn+n...@sni pabacken.sewrot e:

On Wed, 10 Sep 2008 17:06:16 +0500, arnuld <sunr...@invali d.addresswrote:

...

std::cout << "--------------------------------"
<< std::endl;

I would skip the std::endl here though, and use "...---\n" instead.

Sounds like premature optimization to me.

No, it's more "do not do things without a reason" or "use the
simplest construct which does what I want".

And what do you want? To write data to disk, or to create
confusion when your program crashes?

std::endl is not "the thing you should use instead of '\n'"
(although many people believe it is, for some reason).

Just the opposite. Most of the time, std::endl is preferable.
With '\n', you never know when your data is going to end up on
disk.

My reasoning is the opposite of yours. Most of the time I
don't care when the data hits disk[1], and I make this clearer
by not using std::endl.

If you don't care when it hits the disk, the fastest solution is
not to write it in the first place:-). It will never hit the
disk, but since you don't care when it hits the disk...

Most of the time, I find just the opposite to be the problem; I
can't acknowledge a request until I'll sure that the data has
been physically written to the disk. Which can't be achieved
with a filebuf, so I have to use system level I/O.

Flushing a stream doesn't cause data to "hit the disk", at least
not on the systems I use (Solaris, Linux). It's basically a
memcpy to system memory, no more, no less, with a couple of
updates to control variables.

(OK, I admit I also have this suspicion -- not confirmed by
experiments -- that std::endl means a large performance hit in
some situations. I don't want my Unix pipelines to run at
half the speed because there is extensive I/O flushing
somewhere along the way.)

If you're outputting to a pipe, you almost certainly want at
least line buffering. The other side can't read it until it's
gotten to the OS. (Strictly speaking, what you actually want is
that the other side will be able to read the data "promptly".
If you're outputting a lot of data in a tight loop, and you
actually see a slow down, you might want to consider moving the
flush out of the loop. But you definitely want a flush at the
end of any isolated write.)

[...]

[1] Or whatever endl guarantees on my system; I assume it will at
least leave the application.

endl guarantees a flush. A flush guarantees that the data will
be transmitted to the host environment. I don't know what that
really means under Windows, but under Unix, it only means a
memcpy, more or less, to the system buffer. It's not free
(there is a context switch), but it's not that expensive either.
If the writes were actually synchronized, and you had to wait
for the disk, it would be a different issue. Still a question
of optimization, in a way, but at least on the systems I work
on, a synchronized write takes around 10 ms.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

**James Kanze** · Sep 25 '08, 08:35 AM

Re: sorting the input

On Sep 24, 4:10 pm, Hendrik Schober <spamt...@gmx.d ewrote:

Jorgen Grahn wrote:

On Fri, 19 Sep 2008 13:30:52 -0700 (PDT), James Kanze <james.ka...@gm ail.comwrote:

On Sep 19, 12:55 pm, Jorgen Grahn
<grahn+n...@sni pabacken.sewrot e:
>On Wed, 10 Sep 2008 17:06:16 +0500, arnuld
><sunr...@inval id.addresswrote :

....

For me it's very likely also the first time I disagree with
James. I have seen someone debugging and profiling an
application for a week to no avail, until he was told to
replace 'std::endl' by '\n', which made the code he was
trying to speed up (which wrote big files) ten times faster
and ended all his performance woes.

Which is stupid too. *IF* you have a performance problem, then
it should be an obvious consideration, along the lines of making
a function inline.

If you know what you're doing, I wouldn't even oppose using '\n'
from the start in a tight loop; although it is premature
optimization, there are worse things you can do. But for most
people, as long as there is no performance problem, std::endl is
the way to go.

I've been hammering "use '\n' unless you /want/ to flush"
into quiet a few generations of students since...

Since when? That sounds like the performance problem mentionned
above took place a long time ago. Which means that the
performance difference may have (probably has) become less.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Re: sorting the input

Re: sorting the input

Comment

Comment

Comment