「2014-3-13」Javascript Engine, Java VM, Python interpreter, PyPy – a glance

时间:2022-06-03 00:07:04

提要:
url anchor (ajax) => javascript engine (1~4 articles) => java VM vs. python interpreter => pypy

##
前两天在写《HTTP 初步探究》时,碰见一个问题,放到了 * 上,简单讲,就是对于/#wd=keyword 形式的链接,在 Fiddler 抓包里,并没有看见 wd=keyword 被上传到服务器,但最终,keyword 被正确处理了(HTTP 交互里出现了 GET /s?wd=keyword HTTP/1.1 请求),而整个 HTTP 交互期间没有出现 HTTP/1.1 302 之类的回应。

根据下方的一个回答「The component of the url after the # sign is called the URL Fragment. It is not directly sent to the server as a part of the HTTP request (which is why you don't see it in Fiddler); it is only accessible by the JavaScript running on the page.」以及评论里的补充可知,# 后面的这部分,被称作 URL fragment,仅可被页面运行的 js 处理,顺带还提供了一个链接,是关于不同浏览器对于重定向场景下 #url_fragment 的不同处理。另外,我也找到了一篇博客,《QQ 密码修改的小问题》,也是类似的问题。

「2014-3-13」Javascript Engine, Java VM, Python interpreter, PyPy – a glance

两点印象:1. 前端蕴含丰富的技术含量(请原谅先前滴无知),要懂各种标准、理解网页排版、会做 profiling 以优化页面显示、浏览器兼容性,最深的误解莫过于「用 Dreamweaver 画网页的」;2. Javascript 目测很强大。

##
读了四篇系列文章《The race for speed》(整体观感是不明觉厉…… 囧)。讲述的是,Javascript 是如何从一个未被标准化的浏览器脚本语言(最初的 runtime environment 仅有 Netscape – 即后来的 Mozilla Firefox)演变为现如今拥有庞大社区的通用语言(其运行时除了浏览器,也出现了 Node.js 这样的可编写服务器端网络程序的平台)。

从「Javascript => machine code」的基本流程是「lexical analysis =(tokenised_code)=> parser =(Abstract_Syntax_Tree)=> translator =(byte_code)=> byte code interpreter =(native_code)=> rendering / executing process」,除此之外,类似 Firefox SpiderMonkey 和 Google V8 Javascript engine 都做了大量的优化工作,来更好折衷「更快的载入运行 js 代码」和「让 js 代码跑得更快」,以达成使用 web app 替代 native app 的宏大远景(可谓 think big and do right things to make it happen)。

第三篇文章里看,这些优化工作,似乎不少都和 Javascript 的动态语言特性密不可分,比如 type inference 和 hidden classes,甚至 inline caching 都需要考虑多态缓存……
所谓的「Just-In-Time compilation」则是在一条条编译执行的基础上,缓存一部分编译过的 building block 以降低重新编译的性能损耗(可能还有其他高大上的加速思想);由于 Javascript 的动态特性,还要区分 typed JIT 和 un-typed JIT,有点像「分支预测」,如果 type inference 预测正确,则执行先前已经编译并缓存的机器码,否则算是 miss 并提交给 un-typed JIT 执行进一步编译和执行。

这个系列的最后一篇,展望了 Javascript 的未来。其中提到了正在标准化的 ECMAScript 6 和越来越强大的 WebGL,唔,觉得未来 web app 还真可能会大面积替代 native app,Google 当年的宏大远景很牛逼。点赞。

还有两篇可扩展视野的文章,未读,备份一下:《Chrome V8 Degisn Elements》《Explaining JavaScript VMs in JavaScript - Inline Caches》。后面那篇似乎很厉害的样子,「I want to help JavaScript developers understand how JS engines work. I think understanding the tools you are wielding is of uttermost importance in our trade. The more people would stop seeing JS VM as a mysterious black box that converts JavaScript source into some zeros-and-ones the better.」如果是用 Node.js 开发者,可能深入了解一些 internals 有益于更上一层楼。俺这里就纯粹先 #mark# 了……

##
理清了一下 virtual machine 和 interpreter 的异同,这两天经常看见这两个词,表示略微傻傻分不清楚,伤不起…… 参考这个 * 链接回答一回答二,前者讲的比较抽象,后者讲的比较实在(community wiki),读完了就比较清晰了。

理论上:
virtual machine 是提供了一组类似汇编语言 primitive operation 的运行时环境,也是其上所运行 byte code 的沙盒环境,JVM 不仅仅可以运行 Java 程序生成的字节码,也可以运行 python => JVM byte code 的字节码(只要你可以完成这个编译转换),换句话讲,是和语言无关的。
interpreter 则是和语言息息相关,其名称由来也和动态语言密不可分,静态类型(static typed)语言一般不需要「解释」,类型都是固定的,还解释个毛线呢,直接编译链接执行就完事儿了;但动态类型的语言,可能源程序里写着 someDict 的变量在第一轮循环里是哈希字典、第二轮循环里就变成了字符串,所以,需要 interpreter 好好「解释」。第二个回答里提到「The moral of the story is that primitive data type information is really helpful to a compiler/virtual machine.」值得好好体会,其中的 primitive data type 就是指那些 in-memory storage size 固定已知的元类型……

实际上:
在追求效率的场景越来越多的时代,类似 Python 这样的动态语言,也有 PyPy 这样的第三方实现,能够类似 SpiderMonkey / V8 对 Javascript 所做的那样,通过一系列优化,以提升解释执行的速度、优化内存使用、通过微线程提升并发效率。
有两篇和 PyPy 相关的文章,似乎不错,未读,备份先。《Why PyPy is the future of Python》《Wikipedia processing. PyPy vs CPython benchmark》。#mark# 另外,还有一篇官方文档《Python Speed – performance tips》,有时间通读一遍(总觉得有点 pre-mature optimization 的味道,由于 cPython 的优化不够所以需要在 code 层面避免掉坑。囧 如果真是这样,也算是某个历史阶段的 practical practice 吧,动态语言嘛,有得必有失……)。