I have a concept for which I'm conducting an initial analysis. The broader idea is to create an LLVM, JIT based runtime that would create a platform amenable to scripting languages, but do so while enforcing an optional sandbox environment when dictated by security concerns (browsers, user preferences). With this approach, the community would gain language independence for browsers, as well as enabling much needed standardization over tooling support for debugging, refactoring, and even general editing concerns. The first language I'd like to tackle is ECMAScript / Javascript. So, aside from all the issues with the strategy (getting buy-in from browser / tooling teams, development community), my first concern is that it is even possible. Theoretically, it should be possible to express Javascript in LLVM. But a quick review of existing projects indicates that, while LLVM -> Javascript has been taken on, what I'm seeking has not been done to date. Have I missed anything, or is there any reason not to attempt a project like this? Regards, Julian Klappenbach -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120818/5520ed3b/attachment.html>
Most of the performance wins for dynamic languages are not from the kinds of optimizations that LLVM does; you basically gain performance by doing run-time specialization of dynamic language constructs to become static, which is something that LLVM really won't help you do, and which practically speaking is extremely language-specific. For example, in JavaScript, all numbers are officially doubles, but in many cases it is profitable to runtime-specialize them to be integers, on the other hand, Python distinguishes between floats and integers, but Python integers overflow into arbitrary-precision integers on-demand. For another example, in Python, dictionaries can have any hashable type as their key, but in JavaScript, "objects" (which double as hashtables) can only have strings as their keys (although numbers get implicitly converted to strings which is another big language-specific optimization opportunity). Oh, and in JavaScript "objects" have a number of additional semantics which prevent them from being actually used as pure hashtables! --Sean Silva On Sat, Aug 18, 2012 at 4:39 PM, Julian Klappenbach <jklappenbach at gmail.com> wrote:> I have a concept for which I'm conducting an initial analysis. The broader > idea is to create an LLVM, JIT based runtime that would create a platform > amenable to scripting languages, but do so while enforcing an optional > sandbox environment when dictated by security concerns (browsers, user > preferences). With this approach, the community would gain language > independence for browsers, as well as enabling much needed standardization > over tooling support for debugging, refactoring, and even general editing > concerns. > > The first language I'd like to tackle is ECMAScript / Javascript. > > So, aside from all the issues with the strategy (getting buy-in from browser > / tooling teams, development community), my first concern is that it is even > possible. Theoretically, it should be possible to express Javascript in > LLVM. But a quick review of existing projects indicates that, while LLVM -> > Javascript has been taken on, what I'm seeking has not been done to date. > > Have I missed anything, or is there any reason not to attempt a project like > this? > > Regards, > > Julian Klappenbach > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Not necessarily looking for performance gains from LLVM. Instead, the value comes from having a common base platform which can gain language independence, address security concerns, support common tooling (debugging, editing, etc), and perhaps even introduce common language features (annotations / AOP). I'm envisioning a use case where browsers would utilize this runtime to execute not only javascript, but also python, ruby, etc. Language specific interpreters could be downloaded on the fly to support scripts, and security would be ensured due to the fact that it would be based within the LLVM layer. The LLVM layer would also provide the access point for common browser APIs like access to the DOM and HTML nodes, XSLT, and XHR invocations. This would open up both the browser and current HTML5 application platforms to a wide variety of languages. Some may be quite happy with Javascript, but I'm sure others would be excited to see that stranglehold broken. And for this purpose, I think LLVM would be well suited. It really depends on how much existing work can be leveraged, and how much interest exists within the community to see this happen. -jjk On Sat, Aug 18, 2012 at 9:56 PM, Sean Silva <silvas at purdue.edu> wrote:> Most of the performance wins for dynamic languages are not from the > kinds of optimizations that LLVM does; you basically gain performance > by doing run-time specialization of dynamic language constructs to > become static, which is something that LLVM really won't help you do, > and which practically speaking is extremely language-specific. > > For example, in JavaScript, all numbers are officially doubles, but in > many cases it is profitable to runtime-specialize them to be integers, > on the other hand, Python distinguishes between floats and integers, > but Python integers overflow into arbitrary-precision integers > on-demand. > > For another example, in Python, dictionaries can have any hashable > type as their key, but in JavaScript, "objects" (which double as > hashtables) can only have strings as their keys (although numbers get > implicitly converted to strings which is another big language-specific > optimization opportunity). Oh, and in JavaScript "objects" have a > number of additional semantics which prevent them from being actually > used as pure hashtables! > > --Sean Silva > > On Sat, Aug 18, 2012 at 4:39 PM, Julian Klappenbach > <jklappenbach at gmail.com> wrote: > > I have a concept for which I'm conducting an initial analysis. The > broader > > idea is to create an LLVM, JIT based runtime that would create a platform > > amenable to scripting languages, but do so while enforcing an optional > > sandbox environment when dictated by security concerns (browsers, user > > preferences). With this approach, the community would gain language > > independence for browsers, as well as enabling much needed > standardization > > over tooling support for debugging, refactoring, and even general editing > > concerns. > > > > The first language I'd like to tackle is ECMAScript / Javascript. > > > > So, aside from all the issues with the strategy (getting buy-in from > browser > > / tooling teams, development community), my first concern is that it is > even > > possible. Theoretically, it should be possible to express Javascript in > > LLVM. But a quick review of existing projects indicates that, while > LLVM -> > > Javascript has been taken on, what I'm seeking has not been done to date. > > > > Have I missed anything, or is there any reason not to attempt a project > like > > this? > > > > Regards, > > > > Julian Klappenbach > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120818/c88ef14d/attachment.html>
19.08.2012, 00:39, "Julian Klappenbach" <jklappenbach at gmail.com>:>With this approach, the community would gain language independence for browsersBrowser community is strongly opposed to the idea of having multiple web-faced languages> The first language I'd like to tackle is ECMAScript / Javascript.You can tale a look at llvm-lua project. However, speed of JIT achieved by llvm-lua is much worse than language-specific LuaJIT. [1] http://lists.webkit.org/pipermail/webkit-dev/2011-December/018813.html [2] http://code.google.com/p/llvm-lua/ -- Regards, Konstantin
On Sun, Aug 19, 2012 at 5:57 AM, Konstantin Tokarev <annulen at yandex.ru>wrote:> > 19.08.2012, 00:39, "Julian Klappenbach" <jklappenbach at gmail.com>: > >With this approach, the community would gain language independence for > browsers > > Browser community is strongly opposed to the idea of having multiple > web-faced languages > >The browser development community may be opposed, but the general community of developers appears to think otherwise. I'm looking at the number of languages that are sprouting up that are interpreted into JavaScript (Ceylon, CoffeeScript, etc).> > The first language I'd like to tackle is ECMAScript / Javascript. > > You can tale a look at llvm-lua project. However, speed of JIT achieved by > llvm-lua is much worse than language-specific LuaJIT. > > [1] http://lists.webkit.org/pipermail/webkit-dev/2011-December/018813.html > [2] http://code.google.com/p/llvm-lua/ > >I'll take a look at the performance aspect of LLVM vs language specific JIT. Thank you, your input is very helpful. -jjk -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120819/2de32c66/attachment.html>