I am using gfortran for an application and running the Fortran through a Matlab mex file. I have noticed that in the current directory when I run the Fortran file, on my mac, it creates a fort.9 or fort.16 file, where the 9 or 16 are some arbitrary number. Recently, I have noticed that these fort. files can be GBs big! Generally they are quite small, like a few kBs. I was just wondering what purpose these files have? And second, is there some error I have in my code that is causing them to be so large? I just find it to be very suspicious that they are so large.
I am running GNU Fortran (GCC) 5.0.0 20140824 (experimental) from http://hpc.sourceforge.net/ and my version of mac is OSX 10.8.5.
In Fortran, contrary to most other languages, one can write to a unit (~=file object, or file descriptor in some other languages) without first opening it (connecting the unit to a file). In that case, gfortran will implicitly create a file in the current working directory called 'fort.N', where N is the unit number (other compilers may do something else, but generally do something similar).
So to answer your question, in your code you're writing stuff to those units. Why you're doing that I cannot obviously say without looking at the code in question.
Related
I've inherited a large volume of C++ code for running & monitoring laboratory equipment. Currently the deployment is managed by compiling all of the individual modules (each it's own program) using DevC++, manually moving all the .exe files to a Dropbox folder, and then running them on the host machine manually.
I'm trying to automate this process somewhat to make rolling out an implementation on a new machine simpler and making sure the most up to date binaries are what is running on any given machine quickly. However, I don't know anything about deploying software in a Windows environment (I'm used to working on linux systems where a simple makefile would suffice) What tools (preferably command line) are available to compile & organize binaries in a portable way on windows systems?
Assume that you have a C++ compiler usable on the command line, on one translation unit. For example, GCC is such a compiler (and mingw is or contains a variant of GCC). Assume also that it is capable of linking (e.g. by driving the system linker).
Then you need to use some build automation tool to drive such compilation commands. For example GNU make or ninja (but there are many others). AFAIK they exist on Windows (so you could port your Makefile on Linux to Windows).
Once you have chosen your build automation tool, studied its documentation and understood how to use it, you'll write the relevant configuration file for it. For make, you'll write a Makefile (caveat : tab characters are significant). For ninja, you'll write some build.ninja files (but you'll probably generate it, perhaps with meson).
Notice that some build tools (e.g. cmake) are cross-platform.
BTW, DevC++ is an IDE, not a compiler.
I have a console application written in C/C++. Usually it takes, 5-10 minutes to get compiled on non-windows platforms even though optimization flag is set to -o3. But it takes approximate 1-2 hours to get compiled on Windows platform when optimization flag is set to Full Optimization (/Ox) and Inline Function expansion is set to Any Suitable (/Ob2) in visual studio. This happens in release/debug mode both.
I understand compiler is trying to optimize the code hence it is bound to take more time but isn't it too much time compare to time taken by other compilers(mainly g++) on non-windows platforms.
So far I tried..
Removed unnecessary headers from source and header file, introduced forward declarations wherever possible but no respite.
I analyzed the all header files. Templates are used hardly in 2-3 header files out of ~50 header files in project. These headers are also not widely included in the source files.
I've two observations from this behaviour -
There is nothing terribly wrong in the source code otherwise compilers on non-windows platforms would not be able to finish so quick.
Seems VS compiler genuinely taking more time(1-2 hours) which other compilers are able to do in(10 minutes) but VS compiler can't be that bad. Therefore, I must be missing to change some configuration (apart from optimization).
Does anyone has idea how to find out what is going wrong here ? May be starting point will be to identify compilation time taken by each file. How do I find compilation time of each file ?
Could there be possibility if I can still improve/try something ?
Here are additional details about hardware, source code etc as requested in some of comments
RAM - 8.0 GB RAM
OS - Windows 7 64 bit
Processor - Intel Core i5 2.6 GHz
Visual Studio - 2013 Ultimate
Note - If I disable optimization (set /Od and /Ob0 flags in VS) then program compiles in less than 5 minutes on the same machine.
Source files - approx 55, header and source files each and 80KLOC code.
Does anyone has idea where to start to find out what is going wrong here ?
Not without more details.
Could there be possibility if I can still improve/try something ?
Yes. In particular, consider:
removing any templated code from header files (both included and defined in the .h file), and accessing that code through pimpl (because templates are reevaluated on each pass).
optimizing your usage of precompiled headers
splitting your console application into separate modules (so your build system will only update the dirty binaries on build)
Based on suggestions received in comments, I started by finding out compilation time taken by each file:
Clean project to ensure all *.obj files are removed
Build the project again
Noticed the time stamp for each file and I found a file which was
taking almost two hours to compile.
When I open the source file I see something terribly wrong in the code in contrast to my observation. It is a huge monster file of 27KLOC (Opps!, of course I didn't write this file).
There are 739 instances of a class created dynamically and assigned to an array. Each instance in turn dynamically creates some of its members as well. In shorts thousands of objects are being created in this file.
To ensure that this file is the culprit and VS studio is taking way too much optimizing this file. I disabled the optimization
in this file as proposed by #Predelnik in comments. Voilà! program compiles within couple of minutes now. This source code needs a serious re-factoring.
If someone is facing such problems, I would go as following -
Enable Build-And-Run option and /MP flag. As discussed Here. If there is some problem with the code the parallel projects and file compilations would not help.
Find out if any source file is the culprit as above. I believe the link I found Here is a way to calculate the build time not compile time of each file.
Is there any current, relatively simple way to compile and upload full .c/.cpp files for the Arduino DUE on Linux?
I'm beginning to regularly run into issues using the boilerplate code they provide around the sketches and so far, there is very little in the way of documentation or alternative IDE support for the arduino 1.5 SDK... That and the official 1.0.5 IDE is hopelessly broken for linux right now (serial port issues among other things).
There is a great example here.
He explains what you need and how to use it to be able to upload to the due from the terminal of a linux box.
He has done a great job in helping you set up an environment to compile and upload your c programs onto the SAM3X8E. He even gives you a makefile and sample code. What more could you ask for?
Give it a try, see if it works for you.
Even though you can program in c/c++ for the arduio, the arduino does not "use" c/c++ code alone per se. When you use the IDE for arduino, a few libraries are linked when compiled to give you the "arduino" functions like setup(), and loop() as well as constants such as HIGH and LOW. The arduino language is based off a language called Processing which is written in c.
If you are having troubles with the Arduino IDE, it might help to download an older version. Check out the Previous Releases page on their website.
If that still doesn't work, you could try to build it from the source code. https://code.google.com/p/arduino/wiki/BuildingArduino
I wanted to do the same thing as I really don't like IDE like Eclipse. And I didn't want to rely on Arduino environment. Just something minimalist under ubuntu.
For libraries, I downloaded the ASF (Atmel Software Framework) here http://www.atmel.com/tools/avrsoftwareframework.aspx
For compiling, I installed gcc-arm-embedded from here https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded. This provides gcc-arm-none-eabi.
The last part is 'bossac', the upload tool (just do an apt-get install bossa-cli).
Then, just use Vim or your fav editor, adapt a config.mk (configuration of the ASF's MakeFile) for your own project and once okay, upload the .bin to your board with bossac.
Note that bossac has to be run as root (sudo) if you want it to detect your usb port (/dev/ACM0).
After few days playing with examples provided by the ASF library, you'll be able to use a small subset of headers files (only basic definitions like registers names, bits function names in registers ...) to help you and do all the rest by yourself. I personally even don't use 'drivers' files anymore. I directly access registers with my own methods to get smaller code.
I have compiled a (pretty big) Simulink model to a dll file (using an ert_shrdlib target) and created a simple c++ snippet (in Visual Studio 2012 Express) that loads the library and steps through the model. When I try to compile the solution into an executable, I get the following compiler error:
error C1060: compiler is out of heap space c:\matlabr2011b_x86\simulink\include\simstruc.h
I've tried to search SO as well as google for ways to deal with this, but am yet to find anything that works. I tried to set /Zm to high (2000) and low (256) values, I've tried /Heap with different values, I've tried to turn off parallell compiling, and use a x64 solution platform.
Since the model is something the company has worked on for a long time (and by many people), I don't think I'll be able to do much about that at this point, so I'm hoping there's a way to deal with this in Visual Studio.
Edit:
Yes, in my OP I had not set up the 64-bit compiler correctly, but now I have and I still get the same error.
The simstruc.h header from Simulink that is reffered to in the error message includes some really big structs (~400 elements) and I guess they are the root of the issue. I've tried to set the heap to ridicuolus values (like 20000000000) but it still isn't enough. Seriously though, this workstation has 64GB RAM and should be able to compile this bloody header, surely?!
Found the problem.
It wasn't a problem with the heap, it was a couple of lines of code in the included header (from Mathworks) that my compiler couldn't handle. Once I found them and commented them out it compiled.
Your compiler may have exceeded the address space limit for 32-bit applications. The compiler itself doesn't seem to have a 64-bit version (no love from Microsoft). A 64-bit version of the compiler can be found in vc/bin/amd64 directory. You may have to set PATH accordingly, or just invoke cl.exe with its full path manually.
Try also some other compiler, such as ICC or GCC or Clang. Possibly a different OS too.
Based on feedback I got from this question, I'm interested in using Lazy C++ on my OSX laptop. The Lazy C++ webpage has binaries for Linux and Windows available, but nothing for OSX. There's also a link to download for the Lazy C++ source, but it requires a lzz binary as part of the build process. This creates a situation where I need an lzz binary in order to get an lzz binary.
How can I build lzz on my laptop without an lzz binary? Do I need to do part of the build on a Linux or Windows machine to preprocess the lzz source files, and then transfer the source over to my laptop for building? Or is there something else that I should try?
Given that Lazy C++ appears to be a sort of a preprocessor - generating source files as output - you could probably compile it to completion on a supported platform like Windows, take all the generated files and compile it from these generated files again on OSX.
Depending on how complex the build system (Makefiles, in this case) of Lazy C++ is - this is going to be trivial, very complicated or anywhere in between...