How bad is it, to use JavaScript (CoffeeScript) for implementing a heavy computational task? I am concerned with an optimization problem, where an optimal solution cannot be computed that fast.
JavaScript was chosen in the first place, because visualization is required and instead of adding the overhead for communication between different processes the decision was to just implement everything in JavaScript.
I don't see a problem with that, especially when looking at the benchmarks game. But I often receive the question: Why on earth JavaScript?
I would argue in the following way: It is an optimization problem, NP-hard. It does not matter how much faster another language would be, since this only adds a constant factor to the running time - is that true?
Brendan Eich (Mozilla's CTO and creator of JavaScript) seems to think so.
http://brendaneich.com/2011/09/capitoljs-rivertrail/
I took time away from the Mozilla all-hands last week to help out on-stage at the Intel Developer Forum with the introduction of RiverTrail, Intel’s technology demonstrator for Parallel JS — JavaScript utilizing multicore (CPU) and ultimately graphics (GPU) parallel processing power, without shared memory threads (which suck).
See especially his demo of JS creating a scene graph:
Here is my screencast of the demo. Alas, since RiverTrail currently targets the CPU and its short vector unit (SSE4), and my screencast software uses the same parallel hardware, the frame rate is not what it should be. But not to worry, we’re working on GPU targeting too.
At CapitolJS and without ScreenFlow running, I saw frame rates above 35 for the Parallel demo, compared to 3 or 2 for Sequential.
If JavaScript is working for you and meeting your requirements, what do you care what other people think?
One way to answer the question would be to benchmark it against an implementation in a "good" language (your terms, not mine) and see how much of a difference it makes.
I don't buy the visualization argument. If your "good" language implementation was communicating with a front end you might be able to have faster performance and visualization. You might be overstating the cost of communication to make yourself feel better.
I also don't like your last argument. JavaScript is single threaded; another language might offer parallelism that JavaScript can't. Algorithm can make a huge difference; perhaps you've settled on one that is far from optimal.
I can tell you that no one in their right mind would consider using JavaScript for computationally intensive tasks like scientific computing. SO did have a reference to a JavaScript linear algebra library, but I doubt that it could be used for analysis of non-linear systems will millions of degrees of freedom. I don't know what kind of optimization problem you're dealing with.
With that said, I'd wonder if it's possible to treat this question fairly in a forum like this. It could lead to a lot of back and forth and argument.
Are you seeking a justification for your views or do you want alternatives? It's hard to tell.
Well it's not exactly constant time it's usually measured X times slower than Java. But, as you can see from your results for the benchmark shootout it really depends on the algorithm as to how much slower it is. This is V8 javascript so it's going to depend on the browser you are running it in as how much slower. V8 is the top performer here, but it can dramatically run slower on other VMs: ~2x-10x.
If your problem can be subdivided into parallel processors then the new Workers API can dramatically improve performance of Javascript. So it's not single threaded access anymore, and it can be really fast.
Visualization can be done from the server or from the client. If you think lots of people are going to executing your program at once you might not want to run it on the server. If one of these eats up that much processors think what 1000 of them would do to your server. With Javascript you do get a cheap parallel processor by federating all browsers. But, as far as visualization goes it could be done on the server and sent to the client as it works. It's just what you think is easier.
The only way to answer this question is to measure and evaluate those measurements as every problem and application has different needs. There is no absolute answer that covers all situations.
If you implement your app/algorithm in javascript, profile that javascript to find out where the performance bottlenecks are and optimize them as much as possible and it's still too slow for your application, then you need a different approach.
If, on the other hand, you already know that this is a massively time draining problem and even in the fastest language possible, it will still be a meaningful bottleneck to the performance of your application, then you already know that javascript is not the best choice as it will seldom (if ever) be the fastest executing option. In that case, you need to figure out if the communication between some sort of native code implementation and the browser is feasible and will perform well enough and go from there.
As for NP-hard vs. a constant factor, I think you're fooling yourself. NP-hard means you need to first make the algorithm as smart as possible so you've reduced the computation to the smallest/fastest possible problem. But, even then, the constant factor can still be massively meaningful to your application. A constant factor could easily be 2x or even 10x which would still be very meaningful even though constant. Imagine the NP-hard part was 20 seconds in native code and the constant factor for javascript was 10x slower. Now you're looking at 20 sec vs. 200 sec. That's probably the difference between something that might work for a user and something that might not.
Related
I have a node.js file with several functions. Suppose each of this function require the underscore module. What is the impact on performance of adding var underS = require("underscore"); in each and every function versus declaring a single var underS = require("underscore"); globally at the top? Which is better performance?
I just want to add a generalized answer on top of a precise one.
Never let performance impact the broad organization of your codebase, unless you seriously have a good (measured) reason not to.
"Measured" in this context doesn't mean some micro-benchmark. It means profiled in the context of your actual project.
Ignoring this rule early on in my career bit me hard. It didn't aid me in writing efficient code, it simply diminished productivity to a minimum by making my codebase difficult to maintain, and difficult to stay in love with (a motivating human quality I think is often neglected to be mentioned).
So on top of the "no", you shouldn't worry about the performance of importing modules, I would suggest even more strongly, "no", you shouldn't worry about it anyway even if it did impact performance.
If you want to design for performance, performance-critical loopy code tends to make up a very small fraction of a codebase. It's tempting to think of it as a bunch of teeny inefficiencies accumulating to produce a bottleneck, but getting in the habit of profiling will quickly eliminate that superstition. In that little teeny section of your codebase, you might get very elaborate, maybe even implementing some of it in native code. And there, for this little teeny section of your codebase, you might study computer architecture, data-oriented design for cache locality, SIMD, etc. You can get extremely elaborate optimizing that little section of code which actually constitutes a profiling hotspot.
But the key to computational speed is first your own developer speed at producing and maintaining code efficiently by zooming out and focusing on more important priorities. That's what buys you time to zoom in on those little parts that actually do constitute measured hotspots, and affords you the time to optimize them as much as you want. First and foremost is productivity, and this is coming from one working in a field where competitive performance is often one of the sought-out qualities (mesh processing, raytracing, image processing, etc).
Modules are cached after the first time they are loaded. This means (among other things) that every call to require('foo') will get exactly the same object returned, if it would resolve to the same file.
So basically no, it'll not impact the performence.
I am currently developing a online networking game using Box2D JS and Vert.x as the server->client framework.
I have searched for pros and cons of each and I really believe that a dynamic time step is much better since it does not assume that each client has the same processing power, however, there are some (many) people that think fixed time step is much better.
Please enlighten me.
You can basically throw determinism out the window if your timesteps are not synchronized. Even when they are, determinism is difficult.
Spending less computation on simulation will have real costs that may not initially be apparent. For each different setting (and in the case of dynamic timesteps/iterations, for each different individual execution) the resulting behavior on the same input can be different. You can have a user run on really slow hardware that can potentially completely cheat through your levels.
Determinism is perhaps marginally less important outside of a multiplayer engine context, however simply not having a deterministic system will make it significantly more difficult to reason about pretty much anything (gameplay mechanics, game difficulty, exploits) which can impact nearly every kind of game I can think of. Imagine a puzzle game that wasn't deterministic.
I really believe fixing the timestep is the best way to go. I can't remember clearly enough but in one of our games we were having troubles with dynamic timesteps during collisions. Ofcourse most people would say our collision detection code was either not well written or we could use some advanced techniques like ray casting, but we ended up landing on fixed timestep with a for loop that would do the physics update whenever the delay seemed longer due to slow processing power of device or some other reason (CPU busy?), etc. The process was simple enough and we were all happy with the results :)
I think the creator of Box2D himself is in favour of fixed timestep, I read it somewhere although can't find the resource atm.
Can we assume that you are trying to get the same results for the simulation on all clients? If so I think you need to explain your reasoning why having them all doing different calculations would be a good idea!
Or perhaps you meant that all clients will do the same calculations, but the timestep will vary during as the simulation progresses, but that is quite the headache to implement and debug. For each client to come up with the same (or at least similar) result, they will need to be using the same length timestep for each step, so you will need to send this across the network too, eg. physics step 32241 is 16ms, step 32242 is 18ms. Apart from requiring extra network traffic, each client does not know what length timestep to use until it receives this information. And where does it receive it from? Presumably the slowest client will dictate how fast everybody should be going? I can't see it working any other way. So client also have to continuously let the server know how much processing they can handle, and the faster clients will be dragged down to that level of performance.
But as Steven says, there will also be other problems even after these technical difficulties have been taken care of. Most notably the effect of gravity changes with different timestep lengths, so for example in a platformer, the height your players can jump would be continuously changing. If there are platforms that are normally just reachable, they might suddenly become unreachable when a slower client joins.
If you really did mean that each client will use just whatever timestep length it feels like, that would work but the server would need to send out an official snapshot of the world state at very very frequent intervals to get all clients snyced. Technically this would be much easier to implement, and each client would run as smooth as it could, but with more jerkiness as the world state is corrected to the official one, for clients that run either faster or slower than the server does. Hm... maybe this is the best way after all. You might be interested in this article explaining how Quake3 does something like this: http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
I'm going to develop a comprehensive educational software which runs on the browser and has many visualization and simulation works (electrostatic and electromagnetic visualization, 2D and 3D).
Which language(Processing, javascript or something else) is the best toward my purpose?
The question is indeed broad but I will answer from the experience I've had.
Javascript is not really meant to do mathematical calculations, which is what might be necessary to calculate a lot of E&M phenomenon quickly (Especially if they are not represented as a closed form solution). It really goes into how much detail you want in your graphs as well (More steps = more calculations). You may find yourself needing to do more optimizations to make up for the performance difference.
I did some visualizations of antenna arrays (They had closed form solutions, only simple arrays) in Flash and it worked out ok. Javascript will definitely not be up to par with any 3D simulations you might want to do.
I wonder if Silverlight might be a better solution, because you may find more mathematics libraries for .NET than for Actionscript, that could save you a lot of work of writing the math out yourself (But you might end up doing this anyways because of the performance issues).
As others have suggested javascript is not that strong of a language when it comes to visualization.
Processing is a really good language for what you're trying to do, it's easy to learn and is Java based. Data visualization is built directly into the language, as well as temporal space (ie advance "1 tick" in time and have the visualization react to that.)
Also if you're interested in going that route I'd suggest picking up Visualizing Data which is pretty much a Processing primer.
Flash may be the more common application stack right now for what you are looking for, but Silverlight is looking primed to take the title from them based on the powerful features that it contains.
I would go Flex or Silverlight myself
Plenty of re-usable libraries
Native support for multimedia
Native support for graphics and animation
I'm a little late to the show, but what you want, has been implemented in JavaScript, and you'll find this incredibly useful. I recommend running it under Chrome as the JS processing engine is extremely fast. (You may even want to try Chrome 2 which is even faster)
http://ejohn.org/blog/processingjs/
http://ejohn.org/apps/processing.js/examples/basic/ (91 basic demos.)
http://ejohn.org/apps/processing.js/examples/topics/ (51 larger, topical, demos.)
http://ejohn.org/apps/processing.js/examples/custom/ (4 custom "in the wild" demos.)
See also: http://www.chromeexperiments.com/
I second LFSR Consulting's opinion: Processing is used a lot for educational purposes, it is free, and fast (Java is faster than Flash in general) and easy to learn, so you have faster results. It supports 3D, you can tackle Java libraries for simulation and computing, etc. And it has a great community! :-)
JavaScript is a bit light for such usage. JavaFX is hype, but it hasn't really 3D (although one used Java3D with it) and it is still a bit young.
Flash and Silverlight: no comment, not much experience in the field. OpenLazlo can be an alternative...
You really have two choices ActionScript in Flash or VB.NET/C#/other in Silverlight.
So first you need to decide which of these platforms you will target.
You may be able to split the problem into two parts, the user-interaction and display part, and the heavy calculations part.
If you can move the heavy calculations to a server then you can still show everything in javascript.
One difficulty with javascript is that it is interpreted and you will need to write more of the equations yourself, so there is a performance hit and development time, but it will work without any plugins, unless you don't want to do 3D in the canvas tag.
Flash and Silverlight may have better options, but then you are learning new languages and requiring plugins, depending on what version of Flash you want to use.
Check out processing.js, xcode, and iprocessing!
ProcessingJS is great for data visualization but lacks in interactivity.
You should probably try python. It is a really good language for educational and computational purposes it has a pretty decent community and the syntax is not so tough. Even though it was designed to for command line you can create front end gui's for it using some external package and it also provides packages like Scipy, Numpy and Matplotlib for advanced plotting and data visualization.
I'm talking about things like page/stylesheet caching, minifying javascript, etc.
Half of me thinks it's better to do these things as early as possible while still in development so I can be consciously aware of more realistic speed and response issues as well as interacting with something that more closely resembles what will be deployed into production, but the other half of my brain thinks it makes more sense to not do anything until just before launch so that I'm constantly working with the raw data that has not been optimized while in development.
Is there common or conventional wisdom on this subject?
I do all optimizations at the end. That way I know when something doesn't work it is because the code is wrong. I've tried to optimize things too early at times, and realized that I wasted an hour because I was caching something etc.
Realize that a user spents most of his time waiting on frontend objects to (down)load. Your application may generate html in 0.1 second but the user spends at least 2 seconds waiting on all the images etc to load. Getting these download times to a small number will positively increase the user experience.
A lot can be done already by enabling GZIP and using minified javascript libraries. You should download and install YSlow and configure your webserver with appropriate caching headers. This alone can save hundreds of miliseconds loading time.
The last step is to optimize the amount of images using CSS sprites. Other steps can include minimizing css and javascript, but this will gain the least of all methods I mentioned already.
To summarize, most of this can be done by properly configuring your webserver, the sprites however should be done during development.
I'm a fan of building the site first, then using a user experience profiler like YSlow to do the optimizations at the very end.
http://developer.yahoo.com/yslow/
I should add that a profiler of some sort is essential. Otherwise, you're optimizing without before/after data, which is not exactly scientific (not to mention you won't be able to quantify how much improvement you made).
Premature optimization is the root of all evil :)
Especially early in development and even more so when the optimizations will interfere with your ability to debug the code or understand the flow of the program.
That said, it is important to at least plan for certain optimizations during the design phase so you don't code yourself into a corner where those optimizations are no longer easy to implement (certain kinds of internal caching being a good example).
I agree with your premise that you should do as much optimization in the early stages as you can. It will not only improve development time (think: saving 1/2 seconds per refresh adds up when you're spamming control+r!) but it will keep your focus in the end -- during the time when you're refacting the actual code you've implemented -- on the important stuff. Minify everything that you won't be modifying right off of the bat.
I agree with the other half of your brain that says 'do what you have to do, and then do it faster'. But for anything you do you must know and keep in mind how it can be done faster.
The main problem I see with this approach is that at the end its easier to ignore the fact that you have to optimise, especially if everything seems to be 'good enough'. The other problem is that if you are not experienced with optimisation issues you may indeed 'code your self in a corner' and that's where things tend to get really ugly.
I think this might be one where it's difficult to get a clear answer, as different projects will have different requirements, depending on how much work they are doing on the client side.
Mine rule of thumb would be probably later rather than sooner. Only because a lot of the typical front-end optimisation techniques (at least the stuff I'm aware of) tend to be fairly easy to implement. I'm thinking of whitespace stripping and changing http headers and so forth here. So I would favour focusing on work that directly answers the problem your project is tackling; once that is being addressed in an effective way move onto stuff like optimising front-end response times.
After coding for a number of years, you get to have a pretty clear idea what the performance bottle necks will be.
DB Queries
JS/Jquery functions
cfc's
images
javascripts
By identifying the bottlenecks ahead of time, while you create/modify each piece of the application that deals with those bottlenecks, you can spend time tweaking, knowing that by spending time while coding, gives you better performance in the end.
Also tends to make us less lazy, by always creating optimal code, and learning what that is in real life.
I've ported an Excel retirement calculator into Javascript. There are 35 worksheets in the original Excel containing many recursive calculations, all of which I've converted to Javascript. Javascript is running slower (1-2 seconds compared to Excel's instantaneous).
I am caching the recursive calculations already to speed things up and prevent stack overflows in the browser.
Is it realistic to try and make the the Javascript faster?
How does Excel manage to be so efficient?
I read somewhere that Excel only re-calculates when a cell's precedents have been modified. Even still, it seems to me that Excel is pretty much instantaneous no matter how much data needs to be re-calculated.
Excel is faster because it's a few layers closer to the CPU -- running compiled bytecode within the OS, rather than within a browser running interpreted JavaScript.
I'd compare performance with Google Chrome or FF3 that have a new generation of JavaScript engines and see how things improve. See John Resig's post: http://ejohn.org/blog/javascript-performance-rundown/.
JavaScript is slower than any compiled language out there, that's why Excel is so much faster. I would use Firebug's profiler to figure out where your code is spending most of its time and focus on improving that.
If you've ported the Excel formulas to JavaScript while preserving the algorithms intact, the JavaScript code that you've ended up with may not be the most ideal for JavaScript. Have you considered refactoring things to take advantage of JavaScript's powerful language features?
Also, are you rendering things (updating table cells etc.) while doing the calculations? Keep in mind that some DHTML updates may put a big burden on the browser (hey, you're running this inside a browser, right?) Perhaps separating the calculation and rendering may help. You'd first busily do all the calculations and then do the presentation as the final step.
Like other people have said, JavaScript is nowhere near as fast as a compiled language. Currently, there's somewhat of an arms race between Chrome, Firefox and Webkit's JavaScript interpreters, which has really improved the speed situation with JavaScript. However, it's still pretty slow, and if you're using IE7 (or even worse IE6), performance can be pretty dismal.
You may want to look at some of the JavaScript libraries that are out there (personally, I prefer jQuery) to see if some of them have utility functions that you could take advantage of. Some of the more heavily used JavaScript libraries may have optimized some of the work that you're trying to do. It certainly won't make JavaScript as fast as Excel, but if you can replace a lot of your functionality with utilities that have been optimized by many different people, you could see a little bit of a speed increase.