Most portable compiler: llvl llc or pcc or gcc rtl?

[Keith Thompson]

On 11/10/2012 15:45, jacob navia wrote: [...]

Yes. In general, Microsoft compilers outperform gcc by a wide margin

Microsoft's compilers under-perform compared to almost any realistic C
compiler, because they don't support modern C.

I agree that Microsoft's failure to support C past the 1990 standard is
a problem, but it's not a performance issue.

[...]

 

[88888 Dihedral]

There are examples such as avr and dsps as guides. Lots of

documentations to follow and learn.

To get a good job is equivalent to a MSc thesis, because some of them

did it for their thesis.



However, I am only interested to do the basics, just as limiting the

data types to just a few.

If I can get some form assembler sources, it will be enough.

The first stage is just to compile and generate cross assemblies

first.



I have got a feeling that current compilers are getting portable. They

just need more documentatiions to enable people

to port to many architectures. The techniques can be improved further.

Instead of just for speed, we can optimise for

portablility. Just like the old pcc, and now resurrected.











It may be bulky but machines are so fast, they become so

insignificant. We are working with Terabytes now.

Well, for those critical heavy processing parts in C,
I'll consider to transform some parts into assemblies of the native
hardware platforms if I could be paid well.

I think this is the spirit of turning non-commercial projects
into commercial projects.

 

[88888 Dihedral]

David Brownæ–¼ 2012å¹´10月11日星期四UTC+8下åˆ11時06分08秒寫é“：

I thought Apple used llvm rather than gcc - but I could be wrong.







Microsoft's compilers under-perform compared to almost any realistic C

compiler, because they don't support modern C.



A quick google does not show any evidence for your claim - it shows a

mixed bag of results depending on who tested, what code was tested, what

versions were used, etc. From my very unscientific survey, it looks

like the bias is that MSVC generates slightly faster code than gcc.








Again, I can find no evidence for such claims.



It seems to be the case that Intel's compiler can generate better SIMD

code automatically than gcc can, so for code that benefits greatly from

SIMD (but which does not have explicit SIMD code) will get a big boost.

Other than that, it appears that Intel's code is a bit faster than gcc's.



Of course, MSVC is restricted to windows, and Intel's compiler is

heavily tuned for Intel processors (though obviously it supports other

x86/amd64 chips) - while gcc and llvm support a wide range of targets

and hosts.



The most comprehensive benchmark I have seen is this one:



<http://www.willus.com/ccomp_benchmark2.shtml?p18+s14>



That puts gcc 4.6 at 18% behind Intel, and MSVC at 24% behind.



But of course benchmarks are never absolute unless /you/ run them on

/your/ system using /your/ code.

In my experience of C compilations of programs I always test
the followings :

1. malloc, memcpy, memset for different block sizes
2. compute sums of int, float, and double arrays in the pointer version
and the array version for differences in speeds of executions

3. calling methods customizable to use and link
with object libraries in basic, fortran pascal, lisp and etc..

4. assembly embedding

5. testing for unbuffered-buffered I/O in peripheral device drivers

Most of these are not related to language issues but man-years spend
in the the c compiler to be fine-tuned to work with the
specific os and the matched hardware platform.