3 ms·
Trying to write JavaScript that takes advantage of a single engine such as V8, hidden classes, type immutability, performance of 31 vs 32 bits, lack of 64 bit i
by jorangreef 14y ago
Trying to write JavaScript that takes advantage of a single engine such as V8, hidden classes, type immutability, performance of 31 vs 32 bits, lack of 64 bit integer operations, cost of closures, etc. in the end, you spend so much time trying to work within this indirection that C begins to look far less wasteful and more direct, in terms of both human and machine time, especially if you have the general design of what you're trying to do figured out.
- derleth 14y agoThis gets at one of the reasons I like Common Lisp: Common Lisp allows you to program at a high level and then stepwise refine your program to make it more efficient, such as by adding type declarations, adding other declarations, changing your data types, and, at an extreme, changing your algorithms to run without CONSing (that is, eliminating dynamic allocation and garbage collection), not to mention whatever your specific implementation provides as an extension to the standard. Most code can stay fairly high-level, but the tools are there and a standard part of the language if you need them.
- agumonkey 14y agoI've seen some lispers going 'full stack' programming. Clojurians (like this guy http://www.learningclojure.com/2010/09/clojure-is-fast.html http://www.learningclojure.com/2010/09/clojure-is-fast.html) also aim to cpu cycles when they program. It's an interesting workflow to prototype high and fast and the project it down baremetal.
- _delirium 14y agoThe fact that Lisp systems have traditionally included an easy-to-use asm inspector right in the environment is an interesting aspect imo. It's actually more common in my experience for Lispers to look at their generated asm than it is for (non-embedded) C coders to do so, because it's so easy to just (disassemble #'foo).
- agumonkey 14y agoIt's indeed nice to have direct connection between high and low. It's also in lisp culture to unfold layers of code transformations rather than stay in your own isolated layer and relying blindly on 'external tools' that will never be as integrated syntactically and systemically as ... well lisp. Lisp aside, having this point of view seems to be a good goal to reach. ps: There's also one very important lower layer, the memory/cache subsystem.