PythonTip >> 博文 >> PyPy python

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

zihua 2014-03-15 15:03:28 点击: 934 | 收藏


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

##
前两天在写《HTTP 初步探究》时,碰见一个问题,放到了 stackoverflow 上,简单讲,就是对于 /#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 密码修改的小问题》,也是类似的问题。

image

两点印象: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 的异同,这两天经常看见这两个词,表示略微傻傻分不清楚,伤不起…… 参考这个 stackoverflow 链接回答一回答二 ,前者讲的比较抽象,后者讲的比较实在(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 吧,动态语言嘛,有得必有失……)。

原文链接:http://www.tuicool.com/articles/eaMJRby

作者:zihua | 分类: PyPy python | 标签: pypy python | 阅读: 934 | 发布于: 2014-03-15 15时 |