GNU Compiler Collection还有C 编译器、Fortran编译器，并且支持包括x86-64和ARM在内的不同指令集。C语言从源代码到执行，要使用编译器来编译（compile）、汇编（assembly）并连接（link）所依赖的库，形成机器可执行文件。执行这个二进制文件时，操作系统会为程序分配内存和CPU资源。
“编译”和“汇编”，相当于将C语言翻译成底层语言。另外，代码中使用了库函数，当我们使用别人写好的函数时，需要将这些前人写好的库函数连接到我们的可执行文件中，否则会调用函数失败的错误。我们将这种需要编译的语言称为编译型语言。编译型语言有C/C 、Fortran等。操作系统和编译器是紧密相连的，不同操作系统所提供的编译环境不同。
Linux和GCC编译器密不可分，Windows有自家研发的MSVC（Microsoft Visual C ）。不同操作系统在管理网络、读写硬盘、图形化等具体的实现方式不同，库函数连接方式不同…可执行文件一般需要调用这些操作系统接口，所以最终连接生成的可执行文件会截然不同。了解了编译知识，就不难明白为什么很多软件提供商对同一个软件会提供Windows、Mac OS、Linux、iOS、Android等多个版本的下载。
因为不同平台的硬件、编译器和操作系统存在着巨大差异，可执行文件完全不同。所以，也就不难理解Windows软件为什么不可能在Mac OS上运行。实际构建一个大型项目时，编译要考虑的问题会更多。比如我自己编写了多个文件，文件1会被文件2调用，所以要先编译文件1，后编译文件2，否则会因为顺序颠倒而报错；还比如编译型语言对所以依赖的库函数非常挑剔，如果版本过低，有可能出现编译错误。
类似的问题会很多，因此编译型语言在编程和调试时更麻烦，实际操作中一般会使用构建工具链（toolchain），根据一定的顺序，从前到后串起来地去编译。解释型语言：Java、Python、R…既然可以将01组成的机器语言抽象成容易编写的C语言，那为什么不能继续再用类似的办法，再做一次包装呢？IT圈的一句名言就是：计算机科学任何领域的问题都可以通过增加一个中间层来解决。
一些大牛忍受不了C语言这样编写和调试太慢，系统平台之间无法共享移植的问题，于是开始自立门户，创建了新的编程语言，最有名的要数Java和Python，这类语言不需要每次都编译，因此被称为解释型语言。matlab、R、JavaScript也是解释语言。解释型语言一般是使用C语言等偏底层的语言做一个或者，编程人员需要先在自己的计算机上安装这个解释器，接下来就只用关心自己的源代码，其他的事情都交给解释器去做。
如果把编译型语言的编译过程比作将源代码“翻译”成机器语言的话，那么解释型语言就是同声传译。编译型语言是一篇提前就“翻译”好的稿子，拿过来就能被读出来，这样肯定更快；解释型语言要等翻译边“听”边“翻译”，速度当然慢很多。不同编程语言的性能测试 - https://julialang.org/benchmarks/C语言和相应编译器经过了几十年的发展，在性能优化上已经达到了极致，一般是所有高级语言中速度最快的。
