 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:XnsA9F5E84C73117seed7@news.povray.org ingo wrote:
>
>
On Win with Mingwing
$ gcc --version
gcc.exe (Rev1, Built by MSYS2 project) 8.2.1 20181207
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
$ time test.exe
real 0m0.065s
user 0m0.015s
sys 0m0.015s
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/13/19 2:53 PM, clipka wrote:
>
> On Windows Subsystem For Linux I see results like the following:
>
> real 0m1.782s
> user 0m0.000s
> sys 0m0.000s
>
my i7
dick@cyd:/tmp/x$ g++ foo.c
dick@cyd:/tmp/x$ time ./a.out
Done.
real 0m1.100s
user 0m0.000s
sys 0m0.018s
dick@cyd:/tmp/x$ uname -a
Linux cyd 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
dick@cyd:/tmp/x$ g++ --version
g++ (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
One of my i5's
[liza:/tmp/x] g++ foo.c -std=c++11
[liza:/tmp/x] time ./a.out
Done.
real 0m1.074s
user 0m0.000s
sys 0m0.016s
[liza:/tmp/x] uname -a
Linux liza 4.4.0-142-generic #168-Ubuntu SMP Wed Jan 16 21:00:45 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
[liza:/tmp/x] g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609
--
dik
Rendered 1024 of 921600 pixels (0%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"EEeeks!" for both the FreeBSD and MinGW results (not your fault obviously).
Can you try again with a `Delay(10)` and `Delay(100)` to see what
happens? And if they behave nicely (i.e. give results of 10s upward and
100s upward, respectively), can you spare some time and try to figure
out what the "sweet spot" is?
In case you're curious what I'm doing: I'm testing whether
`std::this_thread::sleep_for()` is - as advertised by the C++11 standard
- suitable as a portable way of waiting for _at least_ the specified
duration. If that is the case, then `Delay(msec)` should wait for at
least the specified number of millisconds, and thus the entire program
(doing 1000 such invocations in a loop) should wait for at least the
specified number of seconds.
But alas! Standards are only as good as the rigorosity by which they are
implemented.
Am 13.02.2019 um 23:02 schrieb ingo:
> in news:XnsA9F5E84C73117seed7@news.povray.org ingo wrote:
>
>>
>>
> On Win with Mingwing
>
> $ gcc --version
> gcc.exe (Rev1, Built by MSYS2 project) 8.2.1 20181207
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
> $ time test.exe
>
> real 0m0.065s
> user 0m0.015s
> sys 0m0.015s
>
> ingo
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Hi folks,
>
> can a few of you folks please run the following little program on your
> computers and report the time it takes to run?
>...
tok@ava:~$ g++ test.cpp -o test
tok@ava:~$ time ./test
Done.
real 0m1,083s
user 0m0,008s
sys 0m0,015s
tok@ava:~$ g++ --version
g++ (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
tok@ava:~$ grep "model name" /proc/cpuinfo
model name : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
model name : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
model name : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
model name : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
tok@ava:~$ lsb_release -d
Description: Ubuntu 18.04.2 LTS
--
Tor Olav
http://subcube.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:5c64a63c$1@news.povray.org clipka wrote:
> "EEeeks!"
FreeBSD
delay 10
% time test
0.000u 0.001s 0:00.00 0.0% 0+0k 2+0io 0pf+0w
delay 100
% time test
0.000u 0.001s 0:00.00 0.0% 0+0k 2+0io 0pf+0w
delay 1000
% time test
0.000u 0.001s 0:00.00 0.0% 0+0k 2+0io 0pf+0w
Mingwin
delay 10
real 0m0.143s
user 0m0.000s
sys 0m0.000s
real 0m0.068s
user 0m0.000s
sys 0m0.046s
delay 100
real 0m0.064s
user 0m0.015s
sys 0m0.015s
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.02.2019 um 08:15 schrieb ingo:
> in news:5c64a63c$1@news.povray.org clipka wrote:
>
>> "EEeeks!"
>
...
> delay 1000
> % time test
> 0.000u 0.001s 0:00.00 0.0% 0+0k 2+0io 0pf+0w
...
> delay 100
> real 0m0.064s
> user 0m0.015s
> sys 0m0.015s
Now that seems _totally_ bonkers. Can you add some output to the loop,
say `cout << i << endl`, to make sure the compiler isn't just optimizing
away the entire loop?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:5c65ee33$1@news.povray.org clipka wrote:
> _totally_ bonkers
Take a deep breath.
You have been warned,
compiling with the wrong compiler and wrong option creates no errors and
a program that won't run but you don't notice because the test file test
is not called but test (check file types and compare values) that is
already present on the system...
But, the proper results are in:
FreeBSD Clang 6.0
Delay 1
0.000u 0.005s 0:01.07 0.0% 0+0k 2+0io 0pf+0w
Delay 10
0.000u 0.006s 0:10.64 0.0% 0+0k 6+0io 15pf+0w
Delay 100
0.000u 0.005s 1:46.24 0.0% 0+0k 2+0io 0pf+0w
Mingwin g++.exe (Rev1, Built by MSYS2 project) 8.2.1 20181207
Delay 1
real 0m15.822s
user 0m0.000s
sys 0m0.015s
Delay 10
real 0m15.759s
user 0m0.000s
sys 0m0.031s
Delay 100
real 1m49.566s
user 0m0.015s
sys 0m0.031s
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13/02/2019 à 20:53, clipka a écrit :
> But as I presume this is using the Windows scheduler, I expect that
> genuine Linux systems may behave differently, and I'm also interested in
> other platforms (Mac, maybe BSD if some of you folks are using that, or
> actually any system you can get your hands on.)
>
> I have also reason to believe that results may differ between compilers.
> Using g++ 5.4.0 here.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.10
Release: 18.10
Codename: cosmic
====
For gcc:
$ time ./a.out
Done.
real 0m1,096s
user 0m0,000s
sys 0m0,015s
$ g++ --version
g++ (Ubuntu 8.2.0-7ubuntu1) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
====
For icpc:
$ time ./a.out
Done.
real 0m1,094s
user 0m0,000s
sys 0m0,015s
$ icpc --version
icpc (ICC) 19.0.1.144 20181018
Copyright (C) 1985-2018 Intel Corporation. All rights reserved.
====
For clang:
$ time ./a.out
Done.
real 0m1,094s
user 0m0,015s
sys 0m0,000s
$ clang++ --version
clang version 7.0.0-3 (tags/RELEASE_700/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.02.2019 um 08:40 schrieb ingo:
> compiling with the wrong compiler and wrong option creates no errors and
> a program that won't run but you don't notice because the test file test
> is not called but test (check file types and compare values) that is
> already present on the system...
Oh yeah - that's a good one :)
Even better than trying to judge the run-time performance of certain
code under optimization, and typing `g++ -o3 -ffast-math -o test
test.cpp` instead of `g++ -O3 -ffast-math -o test test.cpp`...
> But, the proper results are in:
>
> FreeBSD Clang 6.0
> Delay 1
> 0.000u 0.005s 0:01.07 0.0% 0+0k 2+0io 0pf+0w
>
> Delay 10
> 0.000u 0.006s 0:10.64 0.0% 0+0k 6+0io 15pf+0w
>
> Delay 100
> 0.000u 0.005s 1:46.24 0.0% 0+0k 2+0io 0pf+0w
That's 1.07 ms, 10.64 ms and 106.24 ms, respectively, which makes a lot
more sense :)
> Mingwin g++.exe (Rev1, Built by MSYS2 project) 8.2.1 20181207
> Delay 1
> real 0m15.822s
> user 0m0.000s
> sys 0m0.015s
>
> Delay 10
> real 0m15.759s
> user 0m0.000s
> sys 0m0.031s
>
> Delay 100
> real 1m49.566s
> user 0m0.015s
> sys 0m0.031s
>
> ingo
That, too, makes sense, and indicates that MinGW has a minimum wait of
ca. 15 ms (on average at any rate). Which is fine, as C++11 allows
implementations to wait longer than requested (but not less).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13/02/2019 à 20:53, clipka a écrit :
> Hi folks,
>
> can a few of you folks please run the following little program on your
> computers and report the time it takes to run?
>
> --------------------------------------------------
> #include <chrono>
> #include <thread>
> #include <iostream>
>
> inline void Delay(unsigned int msec)
> {
> std::this_thread::sleep_for(std::chrono::milliseconds(msec));
> }
>
> int main()
> {
> int count = 1000;
> for (int i = 0; i < count; ++i)
> {
> Delay(1);
> }
> std::cout << "Done." << std::endl;
> }
> --------------------------------------------------
>
> On Windows Subsystem For Linux I see results like the following:
>
> real 0m1.782s
> user 0m0.000s
> sys 0m0.000s
>
> But as I presume this is using the Windows scheduler, I expect that
> genuine Linux systems may behave differently, and I'm also interested in
> other platforms (Mac, maybe BSD if some of you folks are using that, or
> actually any system you can get your hands on.)
>
> I have also reason to believe that results may differ between compilers.
> Using g++ 5.4.0 here.
my little contribution on Mac Intel i5 - 2,7 Ghz.
g++ -v :
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
uname -v :
Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016;
root:xnu-2422.115.15~1/RELEASE_X86_64
result :
real 0m1.239s
user 0m0.009s
sys 0m0.019s
--
Kurtz le pirate
Compagnie de la Banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
