Re: Tiny C Compiler Windows 7 Free Download
Hilke Mcnally
Sup every1 ! Once upon the time i thought it would be really interesting to use Tiny C Compiler (tcc) as Rust's backend cuz it may help us provide more optimised binaries i think. This may look not that clever but i've got no experience in interacting with LLVM and building PLs. Can anyone tell me how difficult it would be and will this be useful please?
Anyway, if you want a faster/lighter-weight codegen backend, there is cranelift. Adding a whole new compiler backend is a massive amount of work, so if you have no experience with developing compilers, then you are very likely not up to the task.
I compiled this on Windows with gcc and tcc for C and rustc with target x86_64-pc-windows-msvc (panic = abort) for Rust. GCC gave 84 kb, rustc gave 12 kb, TCC gave 2 kb. Am i stupid and i could optimize Rust variant more? I know smaller binaries != greater speed so i meant optimization of binary size.
It's quite likely that you didn't account for the constant overhead of each language. If you write a much less trivial program, the differences will either dissappear completely or be very small. It's even possible that Rust outright wins at such scales, as at the language level it lends itself more to optimization than C or C++.
Please search for "rust binary size static linking" or something along those lines. You are not the first one to discover that Rust links libraries statically by default. And 84 kb vs 12 kb hardly matters nowadays, because GB and TB-sized storage is commodity.
I mostly program in C/C++ so I conviniently have a GCC compiler for all my compilations. I was wondering if there is a special compiler for Arduino that can be used just like the GCC Compiler? Because just taking a .ino sketch and passing it to the comiler with a few arguments will be a lot easier for me that all those things in the IDE, and furthermore I use Sublime Text as my text editor. And making a C program work in Sublime is as simple as providing it a path to the compiler. So I would like a portable smaller version of the Arduino Compiler that is NOT the whole IDE folder. Hope I get nice answers!! Thanks in advance.
If you only want to use the sublime text editor for programming and not rebuilding the compilation environment of Arduino for fun (which I wouldn't able to help with), you might wanna have a look at the Arduino-cli. It gives you a tool to invoke important function, that normally the IDE does, via commandline (like installing cores and libraries, compiling and uploading). Thats what I'm currently using with sublime for programming in Arduino. It allows me to invoke building an uploading from sublime without having the Arduino IDE open.
If you want to go that way, here are the sublime-build files, that I use for my Arduino Nanos and ATtiny84s. Maybe you can adapt them for your needs. (Note: I omitted multiple variants, that I use to upload on different com ports, because the com port is the only thing, that changes there. Also I'm on Ubuntu, so on Windows or Mac it might look a bit different)
What annoys me most in the Arduino IDE is the lack of supporting multiple files (having horizontal tabs make the number of files to see max 6 or 7, and using .h/.cpp files easily goes most beyond that number).
My preference is using Visual Studio as editor and I do. In your case you can use Sublime editor. Make sure that the .ino file doesn't change (i.e. only make a forward to your C++ classes or code in other classes). This is to prevent synchronization problems between the Arduino IDE and Visual Studio.
If you are working in Windows, I recommend VS2019 Community Edition (free) plus the Visual Micro extension. Gives you all the intellisense features of VS, tabbed edit windows, the works. I came to the Arduino world from Windows programming with C++ & C#, so I was already familiar with the Visual Studio line of IDE's, but I wouldn't have it any other way now.
Make a Windows program by stuffing bytes into a buffer and writing it to disk: no compiler, no assembler, no linker, no nothing! It was the obvious conclusion of my recent efforts to gain more control over what goes into my executables, and this time I could set every bit exactly as I wanted it. Yes, I am still a control freak.
Sorting out the PE header details and determining which fields were actually required was a chore. All my testing was performed under Windows 7 64-bit edition. If you try these examples on your PC, it appears that earlier versions of Windows were more permissive with PE headers, while Windows 8 and 10 may be more strict about empty PE fields.
With the 4 bytes of code now stored inside the header, I wondered if I really needed a section at all. The Windows loader will load the header into memory along with all the sections, so maybe I could just eliminate the .TEXT section completely, and rely on the entry point address to point the way to the code stored in the header?
you should also take a look at Crinkler, which does not only strip the PE header but also compresses the exe during linktime. its a demoscene tool used by many groups for making tiny intros usually starting at 1k sizelimit.
Thing is, given the same code same optimization flags, intel fortran behaves the same for all the OS.
gfortran on windows is 6 times slower than on Ubuntu.
The time are just the running time. The compilation time is excluded.
One cannot say why gfortran is slower than Intel on Windows (and slower than gfortran on Linux) for an undisclosed code. Can you post the code or at least a fragment which demonstrates the speed differential?
Speaking of IO, in fact, it reminds me that, I do notice in windows the file system like NTFS is significantly slower than the linux file system.
It looks like the same NVME SSD can have much higher actual IOPS on linux than on windows.
I guess someone else may have the same experience on windows. That is, even if I use things like RamDisk to do some IO using ram, the speed is almost the same as I do the IO using my SSD.
Such as installing the same MikTex in RamDisk and in SSD, the installation time are almost the same, and I compiling latex files in RamDisk, and on SSD, the time is still the same. I was expecting that if I compile latex files in Ramdisk, the speed will be as fast as hell. But I was wrong, there is no performance gain than running latex on SSD.
The file system of windows is the limitation, not the hardware.
I like the idea is ramdisk actually .
I previous thought that if I install latex in ramdisk, and then compile latex files there, things will be lightning fast! But it turned out to be the speed of compiling latex on randisk is the same as compiling it on my ssd, lol. Because on ramdisk is file system is still NTFS.
I am developing a package in Fortran and I hope it can be used on Win/Linux/Mac. Letting the user installing gfortran and Make on windows is a very convenient choice. Otherwise user need install Intel OneAPI which is also great but does not really optimize for Apple M1.
So I think if gfortran works fine on Win/Linux/Mac, it can be great.
But the issue of gfortran I have met on windows is that its performance is several times slower than on Linux.
Also, gfortran/gcc seems still some compatibility issue with M1 chip. For example, if use a pointer to point to a function/subroutine, gfortran seems can only work with -Og flag. With more than that optimization it will cause some error on M1 chip.
@CRQuantum, I think that many of the statements and conclusions stated in the various posts in this thread are unfair to Gfortran. Not much has been said about which versions of Gfortran were used on Windows, and which emulation layer/DLL support infrastructure was used.
A brief scan of your sources made me suspect that it uses 8-byte integers in many places where 4-byte integers would have sufficed. This choice, naturally, affects performance, but I did not want to spend any time to alter this aspect of the code.
I took your Gitlab sources, and commented out most of the WRITE statements, until the program produced just 16 lines of output. Here are the run times on my NUC (small box PC with low power laptop processor i7-10710U, laptop memory, on a ramdisk, balanced power setting, Win11-64).
I strongly suspected that the difference in the Gfortran times is attributable to Cygwin using (naturally) Cygwin1.DLL rather than the MinGW DLLs. If so, most of the slowdown that you noticed is attributable not to the compiler but to the runtime (which is also used by GCC, G++, etc.). I ran a test to settle my suspicion. I used Cygwin Gfortran to produce .o files, and linked the .o files using the MinGW Gfortran. The resulting a.exe took 2.8 s. This proves that there can be drastic differences in run times of Fortran programs depending on which versions of the GCC RTL are used. We may note in this connection that MinGW was last updated in 2013, whereas Cygwin was updated just two months ago.
You may attempt to modify your code to reduce the number of calls to PYQ_I, or to make it a vector function instead of a scalar, if that is feasible. Secondly, as I mentioned earlier, see if you can be more judicious in using 8-byte integer variables.
I strongly suspected that the difference in the Gfortran times is attributable to Cygwin using (naturally) Cygwin1.DLL rather than the MinGW DLLs. If so, most of the slowdown that you noticed is attributable not to the compiler but to the runtime (which is also used by GCC, G++, etc.).
I see you use cygwin64 on windows 10, and that gfortran cost 0.79s, that is about right.
I wonder how did you achieve that?
I mean I installed cygwin64 and installed gfortran 11.2.0 there, then I compile and run my code there, but I still get slow speed like 2.9s,
image1715840 57.9 KB
Thank you for your suggestions of optimization. Eh, the integer 8 does not really matter I believe, on modern hardware.
On windows and ubuntu, no matter integer 4 or 8, Intel fortran gives the same speed 0.5s.
gfortran on Ubuntu also gives about 0.6s no matter integer 4 or 8, which is decent enough.
It is an illustration code and optimization is not very important but thank you very much all the same, I highly appreciate it!