I wish to develop a JavaScript game engine that uses C++ as a back-end for rendering/updates/collision etc. Pretty much all the heavy lifting stuff.
There would then be C++ classes/functions that are exposed through modifying the isolate variable (or maybe just a native nodejs module). Some of these classes, like the Sprite class, could have its update function overridden by a JS subclass in order to allow users to customize the behavior.
Finally, the game engine would run in a loop within the JavaScript, but every frame would make a call to the C++ context to update/render and all the stuff PLUS there would be tons of calls to check input, collision, etc. Not to mention all the callbacks each subclass would make to the parent classes written in C++.
My concern is that I have read there is significant overhead (more than normal) when calling C++ from the JS context (be it ffi or native modules). Usually it's worth it for the performance, but considering how many calls would be made back and forth between the two languages each frame, perhaps this wouldn't be the best idea? Instead, maybe something like Python would be more appropriate due to its zero overhead (though Python in general is much slower), or a different JS interpreter all together?
This answer is going to be very subjective, it's from observations from my experience that I wouldn't say are very rigorous, I'm working through this issue now myself, and i have not verified my claims with benchmarks. That said...
Yes, calling from JS to C++ is relatively expensive. Certainly more so than calls within pure JS. Substantially more so, in fact, than calls in the other direction, from C++ to JS. I assume that a major cause of the inefficiency is that the javascript engine loses some optimization opportunities.
However, assuming you stick with the V8 engine, calls from JS to C++ will be much faster than calling out into any other language.
Related
Recently i have played a lot with Javascript(Chrome) there are some things that came to my mind.
V8 has a JIT which make code running faster.
Functional programming means you write logic into functions and invoke/combine them by chain, means core functions will be invoked frequently(not its real definition just for get my point).
JIT is one best practice of exchange time with space basically in first time cache machine code of high-level functions and run caches in next time.
So may i say that apps will be faster if write code in FP way and run by VM that has JIT feature.
A good read on this subject is here: http://thibaultlaurens.github.io/javascript/2013/04/29/how-the-v8-engine-works/
Particularly the section that talks about how V8 compiles and injects JIT code
How V8 compiles JavaScript code?
V8 has two compilers!
A “Full” Compiler that can generate good code for any JavaScript: good
but not great JIT code. The goal of this compiler is to generates code
quickly. To achieve its goal, it doesn’t do any type analysis and
doesn”t know anything about types. Instead, it uses an Inline Caches
or “IC” strategy to refine knowledge about types while the program
run. IC is very efficient and bring about 20 times speed improvement.
An Optimizing Compiler that produces great code for most of the
JavaScript language. It comes later and re-compiles hot functions. The
optimizing compiler takes types from the Inline Cache and make
decisions about how to optimize the code better. However, some
language features are not supported yet like try/catch block for
instance. (The workaround for try/catch blocks is to write the “non
stable” code into a function and to call the function in the try
block)
In short, your fastest code is that which does not modify objects or prototypical function definitions after they've been defined
The only way I could imagine would be using Emscripten, but MLTon has no LLVM backend. Is it possible somehow?
I don't think it is, and as I've commented on your other question, I don't see much point in doing so. Many of the optimisations MLton performs are not that relevant on top of an aggressive jit compiler. On the other hand, you would need to compile not just the program, but also port the MLton runtime to JavaScript. In particular, this involves the memory management system. With the Emscripten route, you probably would need to run MLton's garbage collector nested inside JavaScript. That's usually a terrible idea. Especially if you also want to interact with the JS environment in interesting ways, because then you would have to marshall and finalise back-and-forth across the language boundaries, which tends to imply horrible performance and a high potential for space leaks.
For this use case, the direct SMLtoJS compiler is what you want (although the site seems down right now).
I am trying to convert some pre-existing html/JavaScript files to Flex. I tried making some research to see if there was any compiler that compiles code from javascript to actionscript. As far as I can see, there are many ways to transform actionscript to javascript, but I couldn't find any for the other way around. Does anyone know if there is a way to do that, or should I just write my own tool?
I think you will find this will not work well, as AS3 is a strict-typed language, and Javascript is not. Even if such a compiler exists, your ActionScript will likely have problems from the fact that it would create a bunch of generic object.
In short: ActionScript to Javascript works, because Javascript is more permissive, but a lot of structure is lost. Inheritance, Type, etc.
But to go the other way, there is no way to add back in the structure required by ActionScript.
As one of the commenters mentioned, you may need to do this conversion by hand.
One other idea: the Flash player can talk to Javascript. There may be no need to convert the Javascript to ActionScript, instead just create a few functions to talk to the Flash SWF file through its ExternalInterface class. Just keep the Javascript in Javascript.
I highly suggest a complete rewrite, it won't take much time since both of them (JS & AS) are ECMA standard languages (correct me if I'm wrong)
But if you really need an automated way, Try:
Converting your JS to haxe
Compiling output Haxe to AS
It's the easiest solution on top of my mind.
You're better off writing your own tool. There are so many different ways to write javascript, and including the fact that it's untyped, it would be difficult to write a be-all end-all solution that converts everything. If it's a library, it might make more sense to convert opcodes rather than code-to-code, but so much of it depends on how the javascript was written.
It's going to be a pain, that's for sure.
js is untyped, actionscript is "typed". I guess everything could be an object and it would work well
js function scoping is handled differently.
anonymous function calling in actionscript is generally frowned upon, and is a detriment to performance
stuff like setTimeOut in actionscript is also frowned upon, enter_frame and timer are probably more useful
garbage collection in actionscript is handled a bit differently -- as is event dispatching
Disclaimer: This question will be a bit open-ended. I also expect replies to be partly based off of developer preference.
I've been doing some research lately on Express.js (coupled via Node.js) and I'm struggling to find how I would fit either of these technologies into my current workflow for developing websites. Lately I've been working in either Wordpress or Ruby on Rails, the prior will run on Apache, the latter will run on it's own proprietary server (I assume).
Now perhaps I'm just not understanding something, but I fail to see the advantages to enlisting the support of a Javascript-based framework/server. If there are clear cut advantages to making this part of my workflow, what would they be? I haven't been able to find any ways to fit this into (per say) a Rails application or a Wordpress site. Could someone point me in the direction of some better help of implementing these technologies on top of ones I already use?
One last question, what happens if someone has Javascript disabled in their browser? How would a Javascript-based server react (if at all)?
There are two big differences:
Event loop
Node.js is a bit different from the usual Apache concept, because of the way it handles connections. Instead of having synchronous connections, Node uses an event loop to have non-blocking operations. Note that this is not unique to Javascript and there are C and Python based frameworks that also enable a similar event loop approach, however in Javascript it's probably the most natural feeling since this is how JS has worked since it was introduced.
Supposedly, this should enable you to handle more concurrent clients. However, it hasn't had as much real world exposure as the regular blocking solutions so this approach isn't as mature as most current implementations. The actual performance difference is questionable as it depends on the exact requirements for the application.
Code Sharing
This point is much less controversial than the previous difference, but in essence if you have the same language on both the client and the server, you can reuse a lot of the code, instead of having to rewrite your data structures etc in multiple languages, saving you a lot of development time. However, you have to understand that the concepts of server side JS are different from what you know on the browser, such as you don't have dynamic JS with jQuery or Prototype, but it's result and use-cases are more similar to what PHP is widely used for.
The primary advantage of having Javascript as your server-side language is that you're writing your whole system in a single language.
This has advantages in terms of:
Learning curve and mental context switching for the developer
and also in provides some possibility for sharing code between the two environments.
However, this last point is less helpful than it sounds, for a number of reasons, and this is where the disadvantages come in:
Not much code can actually be shared, because of the differences in what the two environments are actually doing. Maybe a bit of validation code, so you know that you're doing the same checks on both client and server, and maybe a few utility functions, but that's about it.
The libraries you use will be completely different between the two as well: jQuery only works on the client, and Node has libraries that are server-specific.
So as a developer, you still need to mentally context switch between environments, because the two environments are different. They may share a language, but their modes of operation are different, and what they do is different. In fact, sharing the language between the two can actually make it harder to context switch, and this can lead to errors.
Finally, it's worth bearing in mind that while Node is getting lots of attention from the developer community, it is still new and evolving quickly: if you're a business considering a it as a development platform, it's probably not quite yet stable enough to base a major project on.
Are there any real-world prototype-based programming languages with a whole development cycle?
"A whole development cycle" like Ruby and Python: web frameworks, scripting/interacting with the system, tools for debugging, profiling, etc.
Thank you
A brief note on PBPLs: (let's call these languages PBPL : prototype-based programming language)
There are some PBPLs out there. Some are being widely used like JavaScript (which Node.js may bring it into the field - or may not!). One other language is ActionScript which is also a PBPL but tightly bound to Flash VM (is it correct to say so?).
From less known ones I can speak of Lua which has a strong reputation in game development (mostly spread by WOW) but never took off as a full language. Lua has a table concept which can provide you some sort of prototype based programming facility.
There is also JScript (Windows scripting tool) which is already pointless by the newcomer PowerShell (I have used JScript to manipulate IIS but I never understood what is JScript!).
Others can be named like io (indeed very very neat, you will fall in love with it; absolutely impossible to use) and REBOL (What is this all about? A proprietary scripting tool? You must be kidding!) and newLISP (Which is actually a full language, but no one ever heard about it).
For sure there are much more to list here but either I do not remember or I did not understood them as a real world thing, like Self).
I would argue that JavaScript is a real world language. The main difference is that it tends to be embedded into lots of different environments rather than being a stand alone development environment.
Aside from the obvious use in a browser, JavaScript can be used on the server side using CouchDB (which is becoming very popular as a database both for websites and the desktop) or Node.js - there are lots of others as well. It can also be used to create desktop applications via seed or gjs.
As for debugging tools, these are included in most web browsers and there are extensions such as firebug.
The approach is different in JavaScript - instead of having a core language and using libraries to access different programming environments, it is embedded directly into these environments.
It doesn't look like it. Checking out the Wikipedia list, I can't say any of them are particularly popular for systems-type or standalone programming. And I have a few theories why:
Inertia - people are more familiar with procedural/procedure-class based languages. In the same way procedural languages are more popular than functional, I think we find it easier to mentally keep track of the objects we've specified beforehand
Less error-prone - When I use a class, I can't use things not specified in that class. It's a bit less flexible, but when working on a large project I'm very, very grateful to be able to look at the spec for an object (even if I've written that object) and know how the object will behave. That is, I know the compiler will probably throw an error if I try to do something stupid like use the wrong variable name.
You mention "scripting/interacting with the system". As far as that goes, classes aren't even particularly popular. One-off scripts may use a few functions, or even just straight procedural code. I know if I write a simple little Python script, I'll have a few simple functions and I'll use builtin objects. It's OO, but I'm not writing anything.
No/not many suitable languages. This is I think the biggest one. Lua's great for embedded scripting, but I don't think it can replace Python/Perl scripts in my toolkit.
Prejudice - the sordid past of Javascript has not been good for prototype-based languages, I don't think. Javascript's actually a pretty nice language, once you see code written by somebody that understands it, but there's still a lot of derision - it's seen like a kiddie language. If you say "I'm a Javascript programmer", it's hard to be taken seriously.
EDIT It's either a sign or a symptom, but most PT languages are embedded or application-specific scripting languages (Lua in games or for UIs, Javascript in webpages or for the UI like in Firefox, etc). I'm not sure why this is, but they are either more suited to application customizing or otherwise-embeddedness, or that's what the common implementations are designed for. Python can be easily embedded into a program, and it sometimes is, but it's more common standalone.
This may be more philosophical than you're looking for, and I'm by no means a prototype-based expert, but I've done a fair bit of Javascript and fiddled with Lua. I stand by my answer, though, based on at least personal experience. YMMV.
I see no reason why a PT language as useful as Python couldn't be written, but it doesn't seem like anyone's done it.
I did not found one and the only candidate (JavaScript) is still spending very first steps (like Node.js).
Still one other valid candidate would be JavaScript! There is a .NET based implementation named IronJS which is implemented in F# and is going pretty well. This way one can have whole .NET development cycle at his toolbox. It is based on DLR and can be used in both .NET and Mono!