- 主题:请问会写编译器,好找工作吗?
人工智能芯片公司都招编译器,待遇优厚,供不应求 。。。
--
FROM 111.206.214.*
就怕这一波芯片潮流过后,一地鸡毛,找不到编译器岗位了
【 在 groundzero 的大作中提到: 】
: 人工智能芯片公司都招编译器,待遇优厚,供不应求 。。。
--
FROM 58.246.10.*
如果编译前后端理论和实用工具都掌握得比较全面的话,到时候转行到相关领域也还好。怕的就是只做后端针对特定芯片进行优化的,那芯片潮流过后确实一地鸡毛还不好转了。
其实编译就是一种语言翻译(从高级程序设计语言到低级语言的翻译),基本原理适用任何语言翻译/转换工作,比如各种不同格式文件的转换,不同高级语言(不一定是编程语言,比如xml/uml之类的)之间的转换等,形式化模型的解析验证工具,复杂文本解析验证转换等等 。即使自然语言处理方面,编译原理也有一定的用处(当然主要还是用于处理形式语言)。还有各种自动/半自动代码生成的软件工具也基本靠编译的功底。
【 在 tiro2008 的大作中提到: 】
: 就怕这一波芯片潮流过后,一地鸡毛,找不到编译器岗位了
:
--
修改:quene FROM 218.16.203.*
FROM 218.16.203.*
现在大部分的岗位都是针对后端优化的
主要原因是arm啥的都支持定制ISA了,各家为了显示自主可控,肯定会加几个定制的ISA。
不过目前看,编译器需求还挺大的
【 在 quene 的大作中提到: 】
: 如果编译前后端理论和实用工具都掌握得比较全面的话,到时候转行到相关领域也还好。怕的就是只做后端针对特定芯片进行优化的,那芯片潮流过后确实一地鸡毛还不好转了。
: 其实编译就是一种语言翻译(从高级程序设计语言到低级语言的翻译),基本原理适用任何语言翻译/转换工作,比如各种不同格式文件的转换,不同高级语言(不一定是编程语言,比如xml/uml之类的)之间的转换等,形式化模型的解析验证工具,复杂文本解析验证转换等等 。即使自然语言处理方面,编译原理也有一定的用处(当然主要还是用于处理形式语言)。还有各种自动/半自动代码生成的软件工具也基本靠编译的功底。
:
--
FROM 58.246.10.*
如果限制于狭义编译(生成低级汇编语言),那么需求确实少,尤其是前端。但如果不限于编译,而是一般的语言翻译(其前后端理论基础仍然是编译原理、形式语言那一套),那么其实这些知识可以适用于许多表面看上去与编译不相干的诸多领域。
后端生成与具体目标处理器关系太过密切,但对编译出的程序性能很重要,但这部分知识很难迁移到其它领域。各种扩充的指令集架构,如果缺乏通用性,仅对特定应用有效的话,或许直接用汇编语言重写一些专用函数库,或许比在编译器中增加新指令集来得容易,对于增强实际程序整体性能二者效果相差不大。
【 在 POWER8 的大作中提到: 】
: 前端需求才是真的少,而且工具比较完善了,定义好了文法,工具直接生成。而且前端一般和程序性能无关,而性能恰恰是编译器最关注的点。另外你能有几个机会做一个新的语言?
: 后端变化快,各种体系结构需求很难统一,在所谓体系结构的黄金时代,各种架构层出不穷。对程序性能影响主要在后端,需要各种trade-off。严格的说,没做过后端,不算做过编译器。
--
FROM 218.16.203.*
中端还是有很大操作空间的 IR 本身的设计 以及 IR 优化的 pass
【 在 quene 的大作中提到: 】
: 如果限制于狭义编译(生成低级汇编语言),那么需求确实少,尤其是前端。但如果不限于编译,而是一般的语言翻译(其前后端理论基 ...
--
FROM 85.76.68.*
华为。。。
--
FROM 124.64.125.*
硬件描述语言,需要编译技术。 后端做综合,估计会有用到类似编译后端的技术
【 在 PrimeTime 的大作中提到: 】
: 华大九天为啥需要写编译器?
:
--
FROM 180.164.178.*