• [招聘] 鉴释科技 高级/初级软件研发工程师或实习生

    公司简介

    鉴释科技是一家明星初创企业,由一群世界一流的软件专家和经验丰富的上市管理人员创建。我们利用我们对软件构建的经验和理解,以及软件系统是如何工作的,来创造一种新的体验,并通过简单的增值操作将其推向市场。我们正努力用我们以客户为中心的解决方案和想法来打破行业,以改善软件开发体验。目前公司已经进入上升期,你可以在这样一个理想的时间加入我们,成为我们成长的一部分,帮助创造和塑造我们的公司文化。我们正在寻找高能的、希望成为一个激动人心的国际团队的一部分的团队成员。

    JOB TITLE: 高级软件开发工程师

    JOB TYPE:  全职

    LOCATION:  上海

    REPORTING TO: 软件研究开发总监

    岗位职责:

    o    改善和增强公司现有静态应用安全测试(SAST)产品,提高缺陷检出率,降低误报率,提升检测速度,降低检测资源消耗

    o    开发公司新的安全测试产品,包括但不限于交互式应用程序安全测试(IAST)产品和动态应用程序安全测试(DAST)产品

    o    提高公司应用安全测试产品对新的编程语言,语言标准和编译器兼容性

    o    开发新的安全测试规则

    岗位要求:

    o    计算机或相关专业本科及以上学历,3年以上静态分析软件、编译器、虚拟机、模拟器或二进制翻译软件开发经验

    o    熟练C/C++和常见数据结构,熟练使用GCC/GDB

    o    实践高度自律工程开发,产出高质量代码

    o    熟悉Linux操作系统和开发环境

    o    熟练使用Shell Script和Python

    o    熟悉常见编译分析技术优先,如控制流分析、数据流分析、指针分析、过程间分析等

    o    熟悉虚拟机、垃圾回收,二进制动态插桩等技术优先

    o    熟悉形式化验证、符号执行等技术优先

    o    良好的团队协作意识,英语口头和书面交流能力优先

    JOB TITLE:  Senior Software Engineer

    JOB TYPE:   Full Time

    LOCATION: China - Shanghai

    REPORTING TO: Director of Research and Development

    MAIN DUTIES AND RESPONSIBILITIES:

    o    Enhance current Static Application Security Testing (SAST) product to increase true positive rate, decrease false positive rate, reduce analyzing time and resource usage

    o    Develop new application security testing product, include but not limited to, interactive application security testing(IAST) and dynamic application security testing(DAST)

    o    Improve the application security testing product compatibility with new programming language, standard and compilers

    o    Develop new security testing rules

    SKILLS REQUIRED:

    o    Disciplines in Computer Science or related major, bachelor or above degree, more than 3 years of experience in static analyzer, compiler, virtual machine, emulator or binary translator development

    o    Good programming skills, expertise in C and C++ and data structure, rich experience in programming with GCC and GDB

    o    Practicing good engineering discipline for writing high quality code

    o    Familiar with Linux operating system and programming environment

    o    Fluent with Shell script and Python

    o    Understand common compiler analysis techniques like control flow analysis, data flow analysis, pointer analysis and inter-procedural analysis is preferred

    o    Familiar with virtual machine, garbage collection, dynamic instrumentation is preferred

    o    Familiar with formal verification and symbolic execution is preferred

    o    Good team working, good written and verbal English communication skills is preferred

    JOB TITLE: 初级软件开发工程师

    JOB TYPE:  全职

    LOCATION:  上海

    REPORTING TO: 软件研究开发总监

    岗位职责:

    o    改善和增强公司现有静态应用安全测试产品,提高缺陷检出率,降低误报率,提升检测速度,降低检测资源消耗

    o    分析开源软件项目静态测试结果,确定测试结果准确率并将潜在的安全问题反馈给开源社区

    o    提高公司现有静态应用安全测试产品对新的编程语言标准和编译器兼容性

    o    开发新的安全测试规则

    岗位要求:

    o    计算机或相关专业本科及以上学历,或2020年应届毕业生

    o    对程序分析,编译器和编译优化技术有浓厚兴趣

    o    熟悉C/C++和常见数据结构,熟练使用GCC/GDB

    o    熟悉Linux操作系统和开发环境

    o    熟练使用Shell Script和Python

    o    良好的团队协作意识,英语口头和书面交流能力优先

    JOB TITLE:  Junior Software Engineer

    JOB TYPE:   Full Time

    LOCATION: China - Shanghai

    REPORTING TO: Director of Research and Development

    MAIN DUTIES AND RESPONSIBILITIES:

    o    Enhance current Static Application Security Testing (SAST) product to increase true positive rate, decrease false positive rate, reduce analyzing time and resource usage

    o    Analyze scan result on open source software and give feedback to open source software community for any potential security issues

    o    Improve the SAST product compatibility with new programming language standard and compilers

    o    Develop new security testing rules

    SKILLS REQUIRED

    o    Disciplines in Computer Science or related major, bachelor or above degree or fresh graduates in 2020.

    o    Strong interests in compiler and compiler optimization techniques

    o    Good programming skills, expertise in C and C++ and data structure, rich experience in programming with GCC and GDB

    o    Familiar with Linux operating system and programming environment

    o    Familiar with Shell script and Python

    o    Good teamwork habit, good written and verbal English communication skills is preferred

    有意者发送简历到:jianxin.lai@xcalibyte.com

    06月15日
  • Re: 有没有能满足下面需求的C预言预编译处理工具?

    lz例子里的targetAddr不是指针类型,函数体内也没对它做过type casting,实际上是没有alias问题的。这里阻碍优化的地方在于编译器不清楚IPCWriteMessage的副作用。如果能认为这个函数是const的,编译器大概率还是能得到lz想要的结果。

    对lz的问题我觉得最佳方案是找人手工改。

    【 在 predacon 的大作中提到: 】

    : 这个例子对别名分析和优化的要求不低

    : 1. 需要知道两个参数指针不别名 (无法分析,需要用户加一个restrict或者const)

    : 2. 编译器需要把内存再细分,然后用标量来替换,一般编译器只做有限的这种优化。可以考虑通过某些选项把小于WORD的内存访问改成bit-wise操作加WORD大小访存,然后全部标量替换。

    : ...................

    2016-12-28
  • Re: C头文件函数声明的必要性质疑

    既然是C语言,直接使用未申明的函数是允许的,所以这个问题在C语言及C编译器里根本不存在。你完全可以不包含任何头文件,不预先申明任何函数原型。

    【 在 Dongguage 的大作中提到: 】

    : 鄙人愚钝,还望各位指点!以下前提是C语言。

    : int i = func(1,2),假设func()没有在头文件中声明,那么编译器在碰到这句代码的时候,不是一样可以判断出下面的信息么?

    : 1. func()返回值是整型

    : ...................

    2016-09-10
  • Re: 大家对spec2006的libquantum优化怎么看
    7_Ye.ppt (489.0 K)

    你老师说错了,libquantum的关键优化技术看附件。

    【 在 ArchLinux (a lightweight and flexible distribution) 的大作中提到: 】

    : 对libquantum很有印象,因为当时跑SPEC的时候跑过这个,老师说libquantum局部性很糟糕,GCC没有ICC优化得好,所以分数差了好多。

    2016-08-10
  • Re: 大家对spec2006的libquantum优化怎么看

    如果他的编译器能100%正确的“意识”到正在编译的程序是dhrystone,这是个好优化。

    【 在 Xaoyao (多帝空魔) 的大作中提到: 】

    : 我知道有人把dhrystone里面的strcmp直接返回false的(dhrystone里面的strcmp的字符

    : 串都不同)

    2016-08-10
  • Re: LLVM/Clang的优化的确厉害

    不懂inline又不是啥丢人的事情。

    在strlen这个例子里,你列的那些东西在编译器做内联分析时根本就不会看。

    【 在 kknd1399 的大作中提到: 】

    : level一下就low了啊

    : 喷就没意思了

    2016-05-26
  • Re: LLVM/Clang的优化的确厉害

    这个不对,这里讨论的不是输入为空串的情况。compiler不做点事整个串都会被访问到,即使最后仅需要判断是否为空串。

    【 在 POWER8 的大作中提到: 】

    : 这做了inline后,长度为0时执行的就已经是一个compare跟一个add加一个branch了,都是ALU的指令,多发射的情况下没多大overhead。这loop也不长,没必要去掉

    2016-05-26
  • Re: LLVM/Clang的优化的确厉害

    你根本就不懂inline……

    语言规范和ABI对struct layout(及array layout)有规定,struct layout和array layout优化会打破这些规定。

    【 在 kknd1399 的大作中提到: 】

    : 在目前gcc的优化架构下面,str len这种优化做不到,我记得gcc要计算代价模型决定优化,但是str len输入不是定长,一个指针,所以没法inline。 这个inline+去掉循环,对人都不是显而易见,就别说gcc了。

    : gcc给提示也不行,就拿你说的spec fp来说吧,你先运行ICC,让ICC给出哪些能simd,然后你人工改代码,加入指导,再用gcc,依然屎一坨。 到今天,gcc有哪个pass做循环交换展开能做好?多面体模型能看了么?

    : gcc也用spec作为性能参考,不是光ICC调优spec

    : ...................

    2016-05-26
  • Re: LLVM/Clang的优化的确厉害

    不能口算就不是显而易见这个是小学生的判断标准,传统inline cost model对于strlen这个大小的可inline函数几乎是100%inline的。

    icc做好autovec原因很简单:

    自家处理器堆了很多新simd指令;icc有付费的hpc客户和他们大量的legacy代码;autovec能提高spec(specfp)的分数

    gcc不做好的原因也很简单:

    有intrinsic;没有付费的hpc客户;没有跑spec分数的压力

    编译器的优化能力真的是需求导向,而不是技术导向的。你能在kernel,libc,apache,mysql和php里找到多少autovec或者循环变换的机会呢?能不能给你惊喜不是判断编译器好坏的条件。

    结构体拆分不是一个正常的优化,严肃的编译器不应该做这样的优化。

    【 在 kknd1399 的大作中提到: 】

    : 不是黑科技啊~但是也不是你看代码能口算出来的吧?

    : simd化没啥好说吧?ICC经常给惊喜,少了好多手写工作量。而且gcc给提示出来的照样不如ICC。那些结构体变换拆分,循环交换展开,gcc都是屎一样啊~

    2016-05-25
  • Re: LLVM/Clang的优化的确厉害

    inline cost model又不是啥黑科技,当然也是显而易见。

    比如你有个应用,算法适用于simd,你会选择用simd intrinsic来写,还是写scalar code然后期望编译器优化?icc simd做得好无非是因为不能直接改spec的代码……

    【 在 kknd1399 的大作中提到: 】

    : 这个显然不是吧

    : inline要有代价模型,这个并不是显而易见的。

    : 你做个编译器比别人少一堆优化,这个不能说风格偏好啥的吧?就是技术不行啊。

    : ...................

    2016-05-25
  • Re: LLVM/Clang的优化的确厉害

    对人显而易见的东西对编译器也是显而易见的。某些优化有编译器做有编译器不做无非是做编译器的人或者公司有不同偏好而已,和编译器好坏、编译器开发者水平高低没关系。

    大多数情况下编译器的inline策略是优于软件开发人员的。

    【 在 kknd1399 的大作中提到: 】

    : 这个对人是显而易见,对编译器不是吧? gcc就没能实现,llvm也没有吧?  而且显然的是不inline没法做这个优化,编译器应该如何判断哪里要inline,哪里不要?

    2016-05-25
  • Re: LLVM/Clang的优化的确厉害

    你居然敢说贵师兄的手笔“没那么神”… 看过这个文件的changelog么:)

    【 在 predacon 的大作中提到: 】

    : 没有那么神啦,这是一个loop idiom

    : 每一个迭代都是消掉最后一个1,所以trip count = popcount(x)

    : void LoopIdiomRecognize::transformLoopToPopcount(BasicBlock *PreCondBB,

    : ...................

    2016-05-25
  • Re: LLVM/Clang的优化的确厉害

    这个不是也很显而易见吗?如果后面比较是是否大于1或者其他常量,icc也能做得很惊艳才有意思。

    不清楚icc用value range propagation还是pattern match来实现的,谨慎估计是后者。

    【 在 kknd1399 的大作中提到: 】

    : 我觉得还是ICC惊艳,ICC能做这种优化:比如你有个get str len,里面是用while( *a++) len+x这种实现的

    : 然后你有个地方是if(get str len),就是判断长度是不是0

    : ICC能帮你把get str len inline,然后把那个while循环干掉,变成只判断*a是不是0

    : ...................

    2016-05-25
  • Re: LLVM/Clang的优化的确厉害

    这个厉害在什么地方?

    【 在 ArchLinux (a lightweight and flexible distribution) 的大作中提到: 】

    http://lemire.me/blog/2016/05/23/the-surprising-cleverness-of-modern-compilers/

    2016-05-24
  • 上海惠普(Hewlett Packard Enterprise)招聘编译器开发初级工程

    职位描述:

    您将成为Hewlett Packard Enterprise经验丰富的优化编译器后端团队的一员,参与HP Enterprise容错服务器系统(Nonstop X)编译器后端的研发工作。本职为为初级职位,不要求有编译器开发经验,适合对编译器、编译优化技术和代码生成技术有浓厚兴趣并愿意在编译器领域长期发展的应届毕业生。

    职位要求:

    * 对编译器和编译优化技术有浓厚兴趣

    * 熟悉Unix/Linux操作系统和开发环境

    * 熟悉C/C++和常见数据结构,熟练使用GCC/GDB

    * 熟悉常见编译优化技术和运行时优化技术优先

    * 熟悉体系结构,性能分析和代码生成技术优先

    * 良好的英语口头和书面交流能力优先

    工作地点:

    上海张江

    联系方式:

    laijx03 AT gmail.com

    2016-03-14
  • Re: 关于处理器的抗软错误方法

    可以参考早期tandem系统。

    【 在 combuster 的大作中提到: 】

    : 处理器的容错设计,以前主要集中在存储单元的加固,如纠错电路,回写。

    : 针对功能控制部件的加固,论文上有提到冗余多线程,冗余执行单元,流水线部分阶段冗余执行,不知道这些方法在实际产品应用中用得多不多?感觉主要还是针对存储器。

    2016-03-10
  • Re: 直接硬件实现jvm为什么行不通?

    我java做得很少,以下内容来自各种道听途说和脑补。

    排除掉编译(jit)优化因素外,java的性能问题来自以下几方面:

    对象堆分配及引用方式访问父类成员带来的数据访问额外开销;

    异常检测和处理,尤其是nullobject和outofbound异常的检测;

    间接调用的开销。

    java的优化方向就不应该和c/c++一样,关注java的ipc有点舍本逐末。

    【 在 yasm 的大作中提到: 】

    : 是。我说的的虚函数优化,就是branch prediction。我看现在的实现,都不讲求这个。至少我知道的davik, 完全不管。

    : 请教大牛能够展开一下java/C# 性能问题有哪些?

    : 我觉得java的代码,小函数特别多, 而davik有不做inter procedures analysis,inliner也不强。很多时候就一个挨着一个的调用。而且java程序一般会依赖若干个库,这样使得program/data locality特别差。

    2016-03-09
  • Re: 直接硬件实现jvm为什么行不通?

    icall的处理可以放到现有的branch prediction框架里。如果可以改ISA的话,可以引入一条指令,比如叫fill_btb .Label(%pc),%gr

    用途有两个,一是把%gr的内容预取到I$,另一个是把%pc+.Label:%gr写入btb。编译器可以在计算出icall target后就调度这条指令,之后再调度其他指令和准备参数。

    我还是认为对现代处理器架构I$ miss不是主要问题。用java和c#的人大部分不知道I$,java/c#的性能问题也不是I$ miss引起的。

    【 在 yasm 的大作中提到: 】

    : java是今天的IT世界的corner stone。C#应该是另一个。

    : 我记得sun最开始提出来java 的时候,还尝试过硬件实现jvm,这个方法为什么行不通?

    : 我承认jvm里面的很多算法并不是通用的,比如gc, 但是gc可以变成软件实现的,比如SoC可以有一个arm core,专门实现parallel gc算法, 跟硬件解释器同时修改ddr。前些年经常提的概念,叫异构多核,就是各干个的。

    : ...................

    2016-03-08
  • Re: open64怎么没人弄个gcc plugin到whirl

    https://www.edg.com/faq/price

    Frequently Asked Questions

    So how much do you charge for a single copy for Windows?

    Sorry, we don't sell end-user products. We only license source code, which probably costs more than you're looking to spend if all you need is a single end-user copy.

    How much does a source code license cost?

    Usually somewhere between $40,000 and $250,000. There are lots of different kinds of licenses, so you'll have to contact us to get a specific quote.

    【 在 yasm (navy) 的大作中提到: 】

    : 不知道,还在读研的时候,听我师兄说的。

    : 刚才想baidu以下edg多少钱,结果发现:

    : 1) 前端成了写javascript的

    : ...................

    2016-02-29
  • Re: open64怎么没人弄个gcc plugin到whirl

    有打算搬到github去,但没时间弄--公司里的人也这么不靠铺。clang to whirl又不是只有pathscale能做,但我们现在没有动力做。

    上次跟nv的人聊还是在2010年,那时候得到的消息是“我们不会用llvm替换open64”,你比较过这两个后端的性能差异吗?用EDG前端还是有些事要做,因为不能把EDG开源,在EDG和open64中间必须隔一层。这一层的代码量差不多等价于gspin+wgen。

    EDG能卖到10w$的话那4个人晚上做梦都会笑醒吧:-)

    【 在 yasm (navy) 的大作中提到: 】

    : 时间太长, 我都忘了域名了。。。你可以吧open64代码弄github上去啊。

    : clang到whirl的那个, Chris又不会拿出来。现在就缺个FE。

    : open64整个还是有很大的价值的, wopt, lno, ipa虽有bugs, 但是整体上框架在那摆着了, 还是能用的。CG也是定制能力很强。

    : ...................

    2016-02-29