Hello i have a program in c++ which add Hello world (50000000) times in front of string and i want to see toke how long. this is my source
#include <iostream>
#include <string>
using namespace std;
int main() {
string str2("Hello");
auto start_t = chrono::high_resolution_clock::now();
for (size_t i = 0; i < 50000000; i++) str2 += "Hello";
cout << chrono::duration_cast<chrono::milliseconds>(chrono::high_resolution_clock::now() - start_t).count() << " milliseconds\n" << endl;
return 0;
}
i checked this source in 3 Different situations:
Situation 1:
os: windows
ide: clion (latest version)
MinGW: 5
CMAKE: 3.8.2
GDB: 7.11.1
c++: 17
compile: Release
and i got this result:
3100 milliseconds
Situation 2:
os: windows
ide: vistual studio 2017
compile: Release
and i got this result:
700 milliseconds
Situation 3:
os: MAC OSX
ide: clion (latest version)
CMAKE: 3.8.2
GDB: 7.11.1
c++: 17
compile: Release
and i got this result:
1200 milliseconds
i checked on windows and mac and i got this results... why? why the result are totally different? all the situations (Release mode and ...) are same!
Your comparisson has no stable basis.
You are comparing your code on different operating systems, with different compilers.
In order for a comparison to actually take place, you need to keep something fixed. For example, you could check with all three compilers in one system, OR in all three systems with one compiler.
Furthermore, try to use the same optimization flags on every compiler, so that they optimize the code in similar fashion.
Related
Describe
I'm writing a toy code with Eigen. But when I try to print the matrix I, unfortunately, meet the segment fault when cout. The following first code is my project code that meets the segmentation fault. I know that if I just write a tiny code as the second code, it works fine. So I don't know what's the matter with my project code for that it failed in the cout as the pictures show.
C++ Code
The most minimum test code is https://godbolt.org/z/GePx5b
#pragma pack(1)
#include <iostream>
#include <Eigen/Dense>
#include <string>
#include <fstream>
#define BUFFER_SIZE 256
#define WORK_SPACE "PositioningSystem/"
using Eigen::Matrix3d;
int main(int argc, char const *argv[]) {
Eigen::Matrix3d m;
m << 1, 2, 3,
4, 5, 6,
7, 8, 9;
std::cout << m << std::endl;
return 0;
}
If you write the first code #pragma pack(1), you will meet segmentation fault, and if you delete it, all work fine.
Finally find the bug
In an include file, I write such a code as the following
#pragma pack(1) //指示struct不进行内存对齐
When I delete this code, all is right. Anyone has any thoughts about this bug?
more about this
The same code with the #pragma pack(1) could run on the arm but failed on x86 platform as discussed above.
x86
OS Linux wang-X556UQK 5.4.0-54-generic #60-Ubuntu SMP Fri Nov 6 10:37:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
ubuntu 20.04 release
gcc Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
eigen 3.3.7
arm
OS Linux iTOP4412-ubuntu-desktop 3.0.15 #20 SMP PREEMPT Tue Mar 31 22:03:51 CST 2020 armv7l armv7l armv7l GNU/Linux
ubuntu 12.04 customed by vender Linaro 12.04 (GNU/Linux 3.0.15 armv7l)
gcc Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
eigen 3.0.5
Yes, I finally successfully overcome the issue. It's the wrong with the #pragma pack. So, please use the sentence following the #pragma pop, just like the new and delete must be the same to make sure the program is right.
pragma pack(push) without corresponding pop leads to stack smashing
https://gitlab.com/libeigen/eigen/-/issues/2074
I did a fresh installation of minGW on windows 7 64 bits, I can compile c++ without errors, however if I try to run the executable, I get
"This version of D:\xampp\htdocs\Dropbox\Dropbox\c\rts\teste\a.exe is not compatible with the version of Windows you're running. Check your computer's system information to see whether ou need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher."
My code is
#include <iostream>
using namespace std;
int main() {
cout << "aaaa" << endl;
return 0;
}
and I'm compiling using
C:\MinGW\bin\gcc -c D:\xampp\htdocs\Dropbox\Dropbox\c\rts\teste\a.cpp -o D:\xampp\htdocs\Dropbox\Dropbox\c\rts\teste\a.exe
I believe GCC is not compiling 16 bit software, since its the last release
I have 3 computers, two of which use Windows 8. Using the latest version of MinGW's g++ (4.8.1-4) my hello world program freezes whenever I compile and run on the Windows 8 computers but not in Windows 7.
#include <iostream>
int main()
{
std::cout << "Hello, World!" <<std::endl;
return 0;
}
This compiles just fine in g++ but running a.exe will display "Hello, World!" then a window will pop up and say "a.exe has stopped working, Windows can check online for a solution to the program...." etc.
Has anybody seen this problem.
Also, I tried "std::cout << "Hello, World!\n" << std::flush;" and this has the same problem. It seems that every function that flushes the buffer causes a crash.
Following Eric's advice, I recompiled the program and ran it in gdb and got the following output:
Program received signal SIGILL, Illegal instruction.
0x00405065 in _Jv_RegisterClasses ()
In the second instance, the '\n' should cause an output flush in any case, although in Windows I believe console output is immediate (or perhaps automatic after a short timeout) in any case without an explicit flush.
I suggest the following experiments:
1) See if it is specific to the C++ library by using the C library (in MinGW Microsoft's C runtime is used rather than glibc):
#include <stdio.h>
int main()
{
printf( "Hello, World!\n" ) ;
return 0;
}
2) Eliminate the exit code by:
int main()
{
return 0;
}
3) No newline at all:
#include <iostream>
int main()
{
std::cout << "Hello, World! ;
return 0;
}
4) Try different compiler options such as optimisation levels, or -fno-builtin for example, or as suggested here: -static-libgcc -static-libstdc++ (although I doubt ``-static-libgcc` will itself have any effect since MinGW uses Microsoft's C runtime DLL and the static library is only available with Microsoft's tools).
I had the same issue and found after a long painful search that I had multiple versions of the mingw provided libstdc++-6.dll on my computer. One was part of the mingw installation the others were part of other installation packages (gnuplot and GIMP). As I had gnuplot in my PATH the compiled mingw exe it would use an older, incompatible version of this dll and crash with the described symptoms. I can, therefore, confirm Dietmar Kühl's suspicion. As suggested above linking the library statically obviously helps in this case as the library functions are included in the exe at compile time.
It is probably a stupid question but i was searching for the answer from about 3h.
¿How to compile 64-bit binary with (Dev-C++) MinGW?
I have readed that MinGW support 64bits by default, but i am unable to active this option.
I have tryed "-m64" but it say: "sorry, unimplemented: 64-bit mode not compiled in"
I am working on Dev-C++ on Windows-7
I know how to do it on MSVC++, but I don't want MSVC++ (cause of ethical issues)
What i am trying to compile, just for testing purpose:
#include <iostream>
using namespace std;
int main(int argc, char* argv[])
{
// Test compiling mode
if (sizeof(void*) == 8) cout << "Compiling 64-bits" << endl;
else cout << "Compiling 32-bits" << endl;
return 0;
}
To build a 64-bit binary on windows you need the 64-bit version of the mingw compiler. Mingw-W64 is one possible distribution you can use. You can find a list of downloads here.
Additionally, you can also find Dev-C++ setup bundled with mingw 64-bit compiler under Orwell Dev-C++'s download section. Make sure you choose "TDM-GCC x64 4.7.1" either setup or portable.
This code:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello world!\n";
return 0;
}
when comiled give size 457KB in Code::Blocks with GCC 4.4.1 and only 8KB (eight) in VS2010. Both compilers optimized for size.
Anyone knows why such a difference?
This is due to the c++ standard library being linked statically by g++, whereas VS will link it dynamically. A quick check using gcc under cygwin gives me approximately same sizes, and the resulting exe only import some C functions.
#include <stdio.h>
int main() {
printf("Hello world\n");
return 0
}
On the other hand, this application compiled to the same minimal EXE under gcc, as it does not require any c++ functionality.
You are right, the executable by gcc is obviously larger, in your case 57 times larger than that built by vc++.
The main reason is the one made with
GCC won't require any external
dependencies to run while the one made
with VS2010 would need at least its runtime
files to be present on the system.
For instance, say you try it on some friend's computer with no vs2010 installed, rather try earlier OS like XP with no chance of having VS2010 runtimes even.
The one built with GCC will have no problems while the one made with VS2010 would throw an error of missing runtime file ( dependency ).
Hope this helped, if it didn't or you have any other question in your mind, feel free to ask and I'll be glad to help :)