Sunday, September 20, 2020

Digest for comp.lang.c++@googlegroups.com - 10 updates in 3 topics

scott@slp53.sl.home (Scott Lurndal): Sep 20 02:46PM


>I myself compared the speed of std::fwrite() vs. std::ostream::write()
>and noticed a quite clear difference in favor of the former... something
>like 15 years ago.
 
Well Paavo didn't say "from a standard-compliant C++" program.
 
read/write/pread/pwrite are much faster than any of the stdio-based
I/O mechanisms. mmap is also much more efficient. For certain
applications direct access to the device (unix raw files, linux O_DIRECT)
are the most efficient ways to access data.
Paavo Helde <eesnimi@osa.pri.ee>: Sep 20 06:00PM +0300

19.09.2020 22:35 Juha Nieminen kirjutas:
> perhaps related to the hardware, the operating system, or the C runtime.
> But summa summarum, I couldn't get a definitive answer whether fwrite
> is still measurably faster than ostream::write.)
 
I see somehow we got carried away from formatted ouput (fprintf() and
stream <<) to unformatted output (fwrite and ostream::write).
Unformatted output is faster for sure and fwrite and ostream::write
speeds might indeed be comparable, especially if the buffer sizes are large.
 
My claims were about formatted stream <<. For some fun I created a
little test program for comparing formatted output of a custom class A
the "official" stream way, and with a ToString() method suitable for
printf-like interfaces. You should need to call it with stdout
redirected to >NUL or >/dev/null, to leave out any console or actual
disk writing overhead.
 
VC++ 2017, x64 release build:
 
> test.exe >NUL
temp std::string: 0.478026 s
std::ostream::operator<<() : 3.09337 s
 
So it appears ToString() is over 6x faster than <<, with VC++.
 
On the other hand, g++ seems to cope with this test much better and
there the stream << is faster:
 
Cygwin g++ 9.3, -std=c++17 -O2 :
 
> ./a.exe >/dev/null
temp std::string: 0.580246 s
std::ostream::operator<<() : 0.364451 s
 
So maybe you are right in that (some) compiler writers are catching up
and streams are not so slow any more as they used to be. But as VC++ is
one of my major targets I cannot count on it yet.
 
 
The test program itself:
 
 
#include <string>
#include <cstdio>
#include <chrono>
#include <iostream>
#include <algorithm>
#include <random>
 
const int n = 1000000;
 
class A {
std::string name;
std::uint32_t value;
friend std::ostream& operator<<(std::ostream& stream, const A& a);
static std::mt19937 gRnd;
public:
A(): name("A"+std::to_string(gRnd())), value(gRnd()) {}
 
std::string ToString() const {
return name + ": " + std::to_string(value);
}
};
 
std::ostream& operator<<(std::ostream& stream, const A& a) {
stream << a.name << ": " << a.value;
return stream;
}
 
std::mt19937 A::gRnd;
 
int main() {
std::vector<A> data(n);
 
auto start1 = std::chrono::steady_clock::now();
for (const A& ref: data) {
printf("%s\n", ref.ToString().c_str());
}
auto finish1 = std::chrono::steady_clock::now();
 
auto start2 = std::chrono::steady_clock::now();
for (const A& ref: data) {
std::cout << ref << "\n";
}
auto finish2 = std::chrono::steady_clock::now();
 
fprintf(stderr, "temp std::string: %g s\n",
std::chrono::duration<double>(finish1-start1).count());
fprintf(stderr, "std::ostream::operator<<() : %g s\n",
std::chrono::duration<double>(finish2-start2).count());
}
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 20 05:38PM

On Sun, 2020-09-20, Scott Lurndal wrote:
 
> Well Paavo didn't say "from a standard-compliant C++" program.
 
> read/write/pread/pwrite are much faster than any of the stdio-based
> I/O mechanisms.
 
Not if you end up writing a byte (or a few bytes) at a time -- which
is part of the reason stdio exists.
 
(I haven't checked recently, but I guess system calls are still not
cheap.)
 
I haven't followed this thread closely, but it seems a bit
oversimplified to me. It would be easier to discuss a real-life case
where stream output /is/ a bottleneck, and then see what to do about
it.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 20 05:59PM

On Sun, 2020-09-20, Paavo Helde wrote:
...
 
> printf-like interfaces. You should need to call it with stdout
> redirected to >NUL or >/dev/null, to leave out any console or actual
> disk writing overhead.
 
On Linux I often pipe the output to md5sum or similar, so I can be
sure it doesn't change between runs.
 
 
> > ./a.exe >/dev/null
> temp std::string: 0.580246 s
> std::ostream::operator<<() : 0.364451 s
 
Debian Stable: I get roughly the same figures for both.
 
> So maybe you are right in that (some) compiler writers are catching up
> and streams are not so slow any more as they used to be. But as VC++ is
> one of my major targets I cannot count on it yet.
 
(You can, if formatted output is not the bottleneck in your programs.)
 
> The test program itself:
...
 
You should probably have used 'std::cout.sync_with_stdio(false)' here
too. I added it and, oddly, it didn't make any difference for
performance, but I could see from 'strace -c' that the std::cout code
path changed: in terms of system calls it used writev(2) instead of
write(2), and it wrote twice as much at each call.
 
I have seen that flag make a big difference in the past (i.e. a decade
ago).
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Marcel Mueller <news.5.maazl@spamgourmet.org>: Sep 20 11:22AM +0200

Am 15.09.20 um 08:55 schrieb Öö Tiib:
> Interesting trick, jumping to address of called function and letting
> it to return for you.
 
TCO (Tail Call Optimization) is probably as old as the assembler languages.
 
Definitely slow on modern hardware are indirect calls (or jumps) with a
calculated target. They usually result in pipeline stalls because they
are difficult to predict in hardware.
 
Conditional memory access is usually the fastest for min/max if
available on the target hardware.
 
 
Marcel
jacobnavia <jacob@jacob.remcomp.fr>: Sep 20 03:54PM +0200

Le 14/09/2020 à 17:35, Scott Lurndal a écrit :
 
> Given the intel/amd 'CMOVxx' instruction and the ARM "CSET" instruction,
> the compilers will generate the most optimal branchless code for a max
> check even without optimization.
 
In the arm target gcc will generate this code without optimization:
 
18 str x0, [sp, 8]
19 str x1, [sp]
20 ldr x0, [sp, 8]
21 ldr w1, [x0]
22 ldr x0, [sp]
23 ldr w0, [x0]
24 cmp w1, w0
25 bge .L2
26 ldr x0, [sp]
27 b .L3
28 .L2:
29 ldr x0, [sp, 8]
30 .L3:
 
Yes, it generates branches. your assertion above is falsified
Brian Wood <woodbrian77@gmail.com>: Sep 19 07:32PM -0700

On Saturday, August 22, 2020 at 11:59:19 PM UTC-5, Brian Wood wrote:
> has had more homicides this year than all of last year.
> Thankfully, St. Paul isn't as violent/dangerous.
 
> Brian
 
So far there's not much interest in this and I'm
thinking about joining Ben Shapiro and Dailywire in
Nashville:
 
https://www.tennessean.com/story/news/2020/09/15/ben-shapiro-moving-nashville-and-hes-bringing-daily-wire/5812102002/
 
Haven't decided though so am posting again.
 
Brian
Ian Collins <ian-news@hotmail.com>: Sep 20 02:57PM +1200

On 20/09/2020 14:32, Brian Wood wrote:
 
> So far there's not much interest in this and I'm
> thinking about joining Ben Shapiro and Dailywire in
> Nashville:
 
I've never heard of him, is he a C++ writer?
 
--
Ian.
Brian Wood <woodbrian77@gmail.com>: Sep 19 09:01PM -0700

On Saturday, September 19, 2020 at 9:57:58 PM UTC-5, Ian Collins wrote:
> > thinking about joining Ben Shapiro and Dailywire in
> > Nashville:
> I've never heard of him, is he a C++ writer?
 
He's a conservative journalist. He's a modern-day
MLK Jr. in my opinion.
Ian Collins <ian-news@hotmail.com>: Sep 20 04:42PM +1200

On 20/09/2020 16:01, Brian Wood wrote:
>> I've never heard of him, is he a C++ writer?
 
> He's a conservative journalist. He's a modern-day
> MLK Jr. in my opinion.
 
Ah, more crackpot US politics. Irrelevant to the sane world, move along...
 
--
Ian
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)