Weekly Edition
Return to the Development page
| |||||||||||||
Humphrey: Experiments with audio, part X
On his blog, David Humphrey writes about exposing audio data from HTML 5 video and audio elements to JavaScript. The folks working on this stuff are pushing the envelope of what can be done with JavaScript. "Along with the suggestion to use typed arrays also came a less welcome suggestion: remove the FFT calculation from C++ and do it all in JavaScript. When I suggested this in our #audio irc channel, a lot of people were upset, saying that this was a bad idea, that wed never be fast enough, etc. However, I pulled it out anyway in order to force them to try. Corban responded by rewriting his dsp.js library to use Float32Array, which can now do 1000 FFTs on a 2 channel * 2048 sample buffer in 490ms, or 0.49ms per fft (js arrays take 2.577ms per fft, so a lot faster!)." (Thanks to Peter Wason.)
(Log in to post comments)
Humphrey: Experiments with audio, part X Posted May 27, 2010 17:14 UTC (Thu) by cracauer (subscriber, #15239) [Link]
Do what was the time for C++?
Was it using FFTW?
Humphrey: Experiments with audio, part X Posted May 27, 2010 19:50 UTC (Thu) by hughmerz (guest, #34252) [Link] I don't think they've used FFTW. this plot suggests a 2048 element single precision FFT on a 3GHz core 2 duo is ~0.015ms. I've measured it to be around ~0.03ms on a 2.66GHz xeon so they're roughly an order of magnitude slower in javascript.
Humphrey: Experiments with audio, part X Posted May 29, 2010 9:51 UTC (Sat) by roc (subscriber, #30627) [Link]
I don't know how you derived those numbers, but here are some more direct numbers:
https://bugzilla.mozilla.org/show_bug.cgi?id=490705#c49 So C is 1x to 2x faster, depending on the compiler options used. This is using essentially the same code for C and JS. You could squeeze more out of the C code by making it more complex, but many of those optimizations would speed up the JS code as well.
Anyway, the important thing is that JS is fast enough do to FFTs in real time.
This is ebout right... Posted May 29, 2010 11:47 UTC (Sat) by khim (subscriber, #9252) [Link] So dumb C code was 2x faster. The main optimization C needs is better layout to use SSE - and I fail to see how it'll be duplicated in JS. The end result should be around 10x difference between JS and C as hughmerz suggested. But the biggest problem here is the fact that JS implementation is more limited then C implementation! You can not use JS implementation on real web-sites without developing some kind of plugin for MS IE - and if go this route the usual argument "but JS is cross-platform, it works everywhere" becomes moot point. You are stuck with two solution - one with bazillion ready-to-use libraries and another where all these libraries must be rewritten from scratch for zero benefit. If you can find "second Sun" which will sunk billions of dollars in such a project than it can even work, but what will that accomplish?
Humphrey: Experiments with audio, part X Posted May 29, 2010 16:17 UTC (Sat) by hughmerz (guest, #34252) [Link] The first number is taken from the FFTW benchmarking page, you can find a variety of results there, as well as how to convert from the mflops shown in the the plots to time/fft . I use FFTW a lot for scientific work, and happened to have a code fragment on hand to measure the speed, so I double checked that I didn't interpret the plot wrong and measured the speed myself, resulting in the second number. To be clear, I wasn't passing judgement on this work, which is quite interesting in and of itself; I was only providing an answer to the original post and trying to frame the performance numbers. A relative comparison between your homegrown code with X vs Y is interesting to the developers involved, but the wider community need an easily accessible and understandable baseline to compare it with to ascertain it's significance. It's just a matter of different perspectives.
Humphrey: Experiments with audio, part X Posted May 31, 2010 21:23 UTC (Mon) by stevenj (guest, #421) [Link] It looks like misconverted the FFTW numbers by a factor of 2 (probably forgot the factor of 2 for real data). FFTW in that plot got about 9000mflops for size 2048 single-precision real data (Intel MKL got about 11000mflops) on a 3GHz machine from a couple years ago. The conversion to time, from the FFTW page, is: "mflops" = 2.5 N log2(N) / (time for one FFT in microseconds) for real transforms, so this comes out to about 6.3 microseconds (0.0063ms) for FFTW and about 5 microseconds (0.005ms) for Intel MKL. The latest version of FFTW (3.2.2) is actually a bit faster: on my 2.8GHz Core2-ish Xeon, it does a size-2048 single-precision real-data FFT ( This is about two orders of magnitude faster than the numbers the Humphrey folks are reporting for their Javascript implementation, and about 10-20 times faster than the numbers they are claiming for their C implementation. This is not unusual: both of their FFT implementations are basically textbook radix-2 style, ala Numerical Recipes, and it is not unusual for textbook FFTs to be an order of magnitude slower than highly optimized FFTs. No reason for them to be ashamed, though; it's a PITA to get anywhere close to peak performance out of a CPU these days on anything nontrivial, and as long as their code is fast enough for their purposes it might not be worth pulling in a big library like FFTW.
Humphrey: Experiments with audio, part X Posted May 29, 2010 14:44 UTC (Sat) by cracauer (subscriber, #15239) [Link]
There are years of microoptimizations in FFTW, developed by people who know CPUs really well. That's what we need to compare against, not some home-grown new FFT that ignores all that work.
Humphrey: Experiments with audio, part X Posted May 31, 2010 21:09 UTC (Mon) by stevenj (guest, #421) [Link] (The difference between something like FFTW or MKL and a textbook FFT is not really micro-optimizations, i.e. localized tweaks to loops and expressions here and there. You need to change the overall structure of the code much more radically in order to fully exploit caches and registers on modern machines.)
Humphrey: Experiments with audio, part X Posted May 27, 2010 19:30 UTC (Thu) by alankila (subscriber, #47141) [Link]
Well done from firefox team! Let's hope the relevant other browsers follow suit as soon as possible. Without this, generated audio must be played back using a flash or java applet.
Humphrey: Experiments with audio, part X Posted May 27, 2010 23:14 UTC (Thu) by HelloWorld (guest, #56129) [Link]
Am i the only one to think that using JavaScript for audio processing is a gloriously stupid idea? People seem to be so dazzled by the recent improvements in JavaScript performance that they don't realize it's *still* much slower than, say, Java.
Humphrey: Experiments with audio, part X Posted May 27, 2010 23:32 UTC (Thu) by DOT (subscriber, #58786) [Link]
And Java is slower than C, which is slower than assembly, which is slower than microcode, which is slower than hardware. I don't think performance is a deciding factor for using Javascript on the Internet. Besides, there is no reason that Javascript can't improve beyond Java.
Humphrey: Experiments with audio, part X Posted May 27, 2010 23:55 UTC (Thu) by HelloWorld (guest, #56129) [Link]
You're completely missing the point, this isn't about Java being faster than JS, but about JS being unsuitable for the task at hand. If your goal is to push nodes around a DOM tree, then JavaScript sort of makes sense. But audio processing boils down to number crunching, and for number crunching, a high-level language like JS doesn't really make any sense. The algorithms involved aren't much harder to write in a lower-level language, therefore using JS is just a huge waste of CPU time and energy.
Humphrey: Experiments with audio, part X Posted May 28, 2010 0:34 UTC (Fri) by robert_s (subscriber, #42402) [Link]
No, I think you're missing the point. The point is about doing audio processing in an interactive webapp.
Unless you want to tread back into the world of applets that excludes Java.
Humphrey: Experiments with audio, part X Posted May 28, 2010 2:24 UTC (Fri) by HelloWorld (guest, #56129) [Link]
Of course, when all you have is a hammer, everything looks like a nail. But that doesn't make a hammer a good screwdriver, and neither does the fact that current web browsers only understand JS make the latter a sane choice for audio processing.
Well, it's wakelocks all over again :-) Posted May 28, 2010 7:02 UTC (Fri) by khim (subscriber, #9252) [Link] Looks like history repeats itself: while developers of the traditional Web platform are trying to fix unfixable bugs the guys who really bet on the "Web as an application platform" are doing what should have been done years ago. I'm starting to understand why Google decided to stop trying to push Firefox and wrote it's own browser: Firefox people not only don't think about inventing screwdriver - they refuse to accept one even if it's presented to them.
Well, it's processor tie-in all over again :-) Posted May 28, 2010 8:48 UTC (Fri) by eru (subscriber, #2753) [Link] The trouble with nativeclient is that it again shackles the web app to the processor. A lot like ActiveX (maybe minus the security issues, but that remains to be seen). Java code at least is processor-agnostic, as long as a plugin exists for your machine.
And this plugins is released... for which architectures, exactly? Posted May 28, 2010 10:09 UTC (Fri) by khim (subscriber, #9252) [Link] Well, looks like Google thinks about it, but in reality all cross-platform solutions only work if someone cares about support for particular platform. Java promised the world with it's WORA approach - but in the end it works just as well as native code: while lots of C programs run on everything from routers and smartphones to supercomputers Java applications are often tied to quirks of just a single JVM...
Cross platform C vs Java Posted May 28, 2010 17:00 UTC (Fri) by mfuzzey (subscriber, #57966) [Link]
Although a few Java programs may end up being tied to the quirks of a JVM this is IMHO pretty rare today.OpenJDK is available for all the architectures supported by Debian so if you test with that and the Sun JVM you've got most bases covered.
Cross platform C only really works when:
2) Suitable cross platform libraries exist for everything the app needs to do. Once you get beyond the standard C library it starts getting messy quickly. Even though I don't like Java the language much (very verbose) it does have a great standard library that covers the needs of most apps (networking, database, GUI, XML, ...).
Cross platform C vs Java Posted May 29, 2010 11:58 UTC (Sat) by khim (subscriber, #9252) [Link] Although a few Java programs may end up being tied to the quirks of a JVM this is IMHO pretty rare today. My experience is quite different: most closed, proprietary, expensive Java programs don't really like to work with different JVMs. They don't like OpenJDK and they like ported OpenJDK even less. Even though I don't like Java the language much (very verbose) it does have a great standard library that covers the needs of most apps (networking, database, GUI, XML, ...). What functionality implemented in standard Java library is not implemented by at least one free, portable C libarary? Yes, it's sometimes not easy to port C code - but usually that's because authors of said code decided from the start to make it non-portable. And I've only ever had real troubles porting C code from one OS to another OS (from Linux to QNX or from MacOS to Windows), transition between different flavors of Linux or BSD is usually painless if you are not porting some kind of compiler (JIT or some pre-compiler).
Humphrey: Experiments with audio, part X Posted May 28, 2010 14:37 UTC (Fri) by alankila (subscriber, #47141) [Link]
Audio is not a very complex problem because the data rate is so low, typically only 88200 values per second. JavaScript is now much, much faster than that, easily doing millions of computations per second. And in the future, as the CPUs get still faster, and JavaScript interpreters/compilers/runtimes get more efficient, the time for this innovation has come.
If I had a wish-list, here is what I would want: JavaScript library that can efficiently execute linear algebra and vector operations. Start from this Float32Array and provide SSE-optimized vector addition, multiplication, dot, etc. and extend to matrices, in particular the solving of systems of linear equations.
Is this a joke? Posted May 29, 2010 8:50 UTC (Sat) by khim (subscriber, #9252) [Link] I'm surprised to see so many common mistakes concentrated in one post. Audio is not a very complex problem because the data rate is so low, typically only 88200 values per second. Problem with audio is not throughput, the problem is latency. Human can hear 10ms jitter easily. Some even hear 5ms jitter. Note: I'm talking about jitter. It's easy to tolerate 50ms or even 100ms pure latency - if the change comes exactly 100ms after you hit the button it's Ok, but if change happens 20ms in one try and 40ms in the second try - it's already a problem. JavaScript is now much, much faster than that, easily doing millions of computations per second. Yup, but it's still limited by it's design and does not support multicores easily. And in the future, as the CPUs get still faster, and JavaScript interpreters/compilers/runtimes get more efficient, the time for this innovation has come. In the future CPU will be slower form the JavaScript POV. Compare budget Celeron circa 2000 with today's Atom or Tegra2. Celeron will be quite competitive (especially Coppermine-based) and can even win over Atom or Tegra2. Yes, I know, it's "apples vs oranges" comparison - but I'm talking about devices used to surf the web today and 10 years ago. Today CPUs have more cores (even phones have more then two cores today and desktop can have dozen or more), but JavaScript is ill-suited to use them. If I had a wish-list, here is what I would want: JavaScript library that can efficiently execute linear algebra and vector operations. Start from this Float32Array and provide SSE-optimized vector addition, multiplication, dot, etc. and extend to matrices, in particular the solving of systems of linear equations. And what'll you do with all this stuff? You can augment JavaScript and make it decent language, but... why bother? It'll not be backward-compatible solution and if you want to extend browser anyway then sane approach is to use something multicore-friendly and legacy-capable. Who will want to repeat the folly of Sun and burn the billions to produce yet-another mediocre platform? Do you have candidates? Microsoft is smater then that (for all it's talks about CLR it still does low-lever stuff in C/C++), Google is also not so silly. Do you really think Mozilla will have resources to produces something at least barely usable? I'm not saying "good" (it's impossible to have good audio processing in JavaScript), but "usable" is possibility - if you have sizable amount money to burn. Time will tell.
Is this a joke? Posted May 29, 2010 16:59 UTC (Sat) by alankila (subscriber, #47141) [Link]
Nope, it's not a joke.
1. The latency issue.
The latency is validish point, and it is true that interactive programs need to respond to user input in a timely fashion. For instance, if you are writing a full duplex sound processing program, 10 ms is about the most you can afford before the latency becomes noticeable to user. (Imagine a guitar effects processor.) So for this kind of application maximum latency must be very low, and user wouldn't tolerate 100 ms or any other value.
2. Jitter and multithreading
I'm not especially worried about jitter. You can control maximum jitter just by using smaller output buffers, that is, limiting maximum latency. And if you have enough CPU cores and sufficient multithreading within the browser, I would guess that there's always some core available for generating more audio when it needs it. I hope JavaScript will get multithreading at some point, similar to the Workers concept, or whatever. We'll see how it goes.
I confess I was mostly thinking about noninteractive applications when I wrote that audio is an easy problem. Noninteractive audio generator is the easiest problem, as latency doesn't really matter and jitter can't be an issue. However, as to what comes to jitter, I imagine the same problems apply to any graphical response as well, so predictable execution and controlling the latency are very much in the agenda, audio or not.
I assume that even if CPU cores wouldn't improve, or even if they regress, the improvements in JS compiler technology can still roughly uphold status quo. Anyway, the baseline currently set by Atom and like seems to be pretty high to me, so I'm not too worried about this.
3. Why bother with JavaScript?
I like the web. The better application delivery platform it is, the more value there is to the web. Now that Mozilla folks have opened the can of worms by having a special optimized datatype for their audio stuff, they could easily extend that and provide several requisite operations to make JavaScript really sing for several types of number crunching.
And unlike what you seem to think, adding something like element-by-element multiplication and horizontal addition aren't all that difficult nor costly to do, so it certainly won't cost billions, and yet makes it possible to do for instance physical simulations more efficiently. It looks to me like Chrome is coming up behind Firefox and could well eat it away, so either you innovate or die.
Is this a joke? Posted May 29, 2010 17:06 UTC (Sat) by alankila (subscriber, #47141) [Link]
Correction for outdated information on my part. Looks like Workers are already part of Firefox 3.5, so the multithreading issue might well have been solved already.
Well, it looks like you really meant what you said... pity... Posted May 29, 2010 20:07 UTC (Sat) by khim (subscriber, #9252) [Link] 1. For professional work you'll need professional tools. I don't see such things in browser any time soon. I meant things like games. You don't need 10ms latency for Guitar Hero, 100ms is enough (even if not very pleasant), but if latency fluctuates - it's disaster. 2. Jitter does not come from JavaScript - rather it comes from browser core: when JavaScript does something with DOM it introduces delays which are really hard to control. And there are quite limited number of applications where you only need audio feedback and don't need synchronized video feedback. Workers don't help much: they are loosely coupled with browser and the transfer of data from and to worker can take enough time to make your audio work suffer. 3. Adding vector functions to JavaScript is not easy if you want to do it in cross-platform way (SSE, Neon and AltiVec are quite different and it's not easy to invent abstraction which will work well will all such technologoes), but this is not what you'll need billions for. You'll need billions to rewrite all the existing libraries and platforms for the new uber-fast JavaScript! Currently the situation looks like this: Chrome may be behind if you only view web platform as JS+HTML, but if you'll take a look on bigger picture... We'll see how the fight will go, but so far I'm not convinced, sorry. You'll need another stupid company like Sun which will pour good money after bad to push the JavaScript - even then I'm not convinced it'll work adequately to fight Chrome's simple offer of C/C++ in browser...
Well, it looks like you really meant what you said... pity... Posted May 29, 2010 20:50 UTC (Sat) by alankila (subscriber, #47141) [Link]
1. Agreed. Professional tools would be great, but seem about as far away as ever.
Guitar Hero and its ilk can be configured to work on wide scale of latencies, because user sees the interaction event approaching ahead of time, and only has to press button at the right time. The only real impact of latency is the delay until user gets the feedback whether it was a hit or a miss. Jitter is still deadly to gaming experience.
2. A typical audio-generating worker would probably contain an event queue of things it responds to, which is populated via messages posted to that worker. I assume there are no waits involved here, the messages are queued and handled at some convenient opportunity. Therefore I'd expect that the threads don't need to synchronize and the data transfer is at worst a simple clone of the datastructure. I'm also hoping that workers could be used to autonomously play the audio back in the first place (which is a big assumption, if they are truly barred from interacting with DOM and thus presumably the <audio>.)
3. The API would simply consist of the fundamental vector and matrix operations. Not much creativity needed for that! The implementation could do whatever is necessary to lay data out optimally for the underlying architecture. I think for arrays the arrangement would have to be sequential in memory, though.
And nobody has to rewrite anything. The point is to have a way in JavaScript do some serious number crunching efficiently, so that you can actually do some really impressive stuff with JavaScript instead of having to use flash/java/nacl for it. The way these things get done is that somebody whips up a JS library that exposes a nice user-visible stable API, and it then adapts to the browser, using the efficient implementations if they are available.
Isn't it a bit unfair that you tell me how C/C++ in the browser is the best thing in one place, yet berate my hope for good native algebra library for having a problem with multiple CPU architectures? And Workers do implement multicore support. It works in chrome 5 at least, I just tried it.
I think you misunderstood my point... Posted May 30, 2010 16:39 UTC (Sun) by khim (subscriber, #9252) [Link] And nobody has to rewrite anything. The point is to have a way in JavaScript do some serious number crunching efficiently, so that you can actually do some really impressive stuff with JavaScript instead of having to use flash/java/nacl for it. To do "some serious number crunching" you don't need primitives. You need GSL, or may be you need CGAL, or may be you need BLAS, or may be you need LAPACK, or may be you need Eigen, or ... you got the point? You can port them - but someone must do that and someone must support the ports. Who will do that and why? The way these things get done is that somebody whips up a JS library that exposes a nice user-visible stable API, and it then adapts to the browser, using the efficient implementations if they are available. Yes, it's the possibility. But this is repeat of Java disaster - without corporate backing this time. Java is still poor choice for number crunching - why do you think JavaScript will fare better? Isn't it a bit unfair that you tell me how C/C++ in the browser is the best thing in one place, yet berate my hope for good native algebra library for having a problem with multiple CPU architectures? Not at all. JavaScript has one serious advantage over C/C++ in form of NaCl: portability. If you lose that then there are no need to discuss this solution at all: C/C++ does everything else better already. That's why portability has "absolutely vital" status for JavaScript solution, but "nice to have" for C/C++ solution. BTW Google tries to solve this problem too - but AFAICS so far it's just a few diagrams and some research code, not a "ready-to-use" solution...
I think you misunderstood my point... Posted May 30, 2010 18:12 UTC (Sun) by alankila (subscriber, #47141) [Link]
Okay. Retract "serious number crunching". Let's just say "some number crunching". I am not really proposing that JavaScript would suddenly become the de facto language for writing scientific code. But by god, I'm sure that it could at least be improved by addition of mathematically useful primitivies. Think about SciPy's array() type, or something like that.
I find the argument about portability bizarre. We are really not arguing about the JavaScript code running vs. not running, we are arguing about the code running faster on some platform and slower elsewhere, depending on what native means are available, and what the CPU can do, how well the JavaScript can be JIT-compiled, etc. That is a completely different kettle of cod compared to compiled C/C++, where we are usually arguing about some binary blob running on one platform and yet not running at all on some other platform (and not necessarily even compiling / working correctly on some different platform).
We are discussing audio, not scientific number-crunching, right? Posted May 31, 2010 10:04 UTC (Mon) by khim (subscriber, #9252) [Link] Retract "serious number crunching". Let's just say "some number crunching". I am not really proposing that JavaScript would suddenly become the de facto language for writing scientific code. Ok, let's forget about scientific calculations - we've talked about audio from the start, remember? We are really not arguing about the JavaScript code running vs. not running, we are arguing about the code running faster on some platform and slower elsewhere, depending on what native means are available, and what the CPU can do, how well the JavaScript can be JIT-compiled, etc. The difference "works" vs "does not work" is important for scientific calculations, but for real stuff we'll be getting something like this. That's another reason why I'm skeptical about JavaScript: if you can do fast audio processing only in Firefox then you cover just 1/4 of desktops and don't cover mobile at all. That's way worse then exclusive x86-only solution in practical terms.
Humphrey: Experiments with audio, part X Posted May 28, 2010 9:14 UTC (Fri) by elanthis (guest, #6227) [Link]
Uh, actually, there are numerous reasons why JavaScript is incapable of being as fast as Java(tm). Yes, yes, some particular implementation of JavaScript may be faster than some other particular implementation of JavaScript. That's totally irrelevant since technically I can write a completely C99-compliant slow-as-shit interpreter for C and then claim that Bash is faster than C.
When you get down to real technical limitations, the simple fact is that every single trick that the JS implementations pull off can also be used in a Java interpreter. Furthermore, there are a number of tricks that you can pull off in a Java interpreter that you literally cannot do in JavaScript (or PHP, or Python, or Perl, or Ruby, or LISP/Scheme, or whatever other untyped language you might think up). The JIT compiler techniques are obviously not JavaScript innovations. The tracing runtime that Mozilla touted as making its JavaScript engine so fast (even though the non-tracing competing JavaScript engines have all gotten faster than Mozilla's recently) was actually originally implemented in a JVM first! The tracing technique can't even be optimized as well for JavaScript, again because of its dynamic nature (the JIT'd code for JavaScript requires far more type guards than if it were statically typed, which adds more instructions, more branches, etc.).
Likewise, C will always be faster than Java, assuming a good C compiler and a competent developer. The higher level the language, the less control the programmer has and the more "magic smarts" he has to rely on from the language itself. Heck, the modern C compiler already has way, way more smarts than most people realize in terms of instruction ordering, register allocation, prefetching, branch prediction hinting, inlining, and so on. The higher level languages are great for convenience, but the only time Java will be faster than C (or JavaScript faster than Java) is when you're dealing with an incompetent developer, where the smarts of the language are actually smarter than the human. e.g., the cases where a bounds checked array can have the check eliminated by the compiler when the programmer would have explicitly put them in there anyway not realizing that they're unnecessary. In all honesty, I don't think those programmers (the kind that are skilled enough to even think they needs bounds checking but not smart enough to optimize performance critical code) are large in numbers.
Higher level languages are faster for a skilled programmer only when the language provides highly optimized library routines that the programmer would otherwise have to implement himself with less time (and hence less optimization) to dedicate to it. C and C++'s standard libraries are quite anemic, but the total number of available libraries available for both are absolutely freaking enormous (to the point that most popular high-level languages bind more C/C++ libraries than they have native libraries).
... so to sum up that rambling bit: JavaScript will never be faster than Java unless the Java implementations completely stagnate.
Humphrey: Experiments with audio, part X Posted May 28, 2010 9:48 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
Thought I agree with the thrust of your argument, I should at least point out that it isn't correct as stated.
This is because of our friend Turing equivalency. In the same way that we can imagine the box that contains all human conversation and thus passes a naive Turing test while being non-sentient, we can imagine a box which translates Javascript into exactly equivalent Java. At this point it becomes obvious that exactly all the same optimisations are available.
The practical reason it doesn't work out this way is that the two languages encourage different styles of programming. A program written in Javascript in such a way that the hypothetical translator produces optimal Java from it, likely does not resemble any program a Javascript hacker would ordinarily produce. So the issue isn't that language A is inherently slower than language B, but that the way people tend to program in language A is harder to optimise.
To attend to a specific issue: Suppose language A has untyped variables. I can clearly signpost to the machine that I use a particular variable only for floats. (e.g. it may be that always writing + 0.0 in assignments would be an effective way to do this, I haven't thought too hard about it) and then it could, in theory, optimise access to this variable just as well as a typed variable in another language.
This isn't necessarily a criticism. If you can, in half the time, write code that runs 10% slower, it is very likely worthwhile to do this for the bulk of your software.
Humphrey: Experiments with audio, part X Posted May 28, 2010 18:52 UTC (Fri) by HelloWorld (guest, #56129) [Link] we can imagine a box which translates Javascript into exactly equivalent Java.Such a box can never exist due to Rice's theorem. It is in general impossible to tell whether a given JavaScript program is equivalent to a given Java program.
Humphrey: Experiments with audio, part X Posted May 28, 2010 19:13 UTC (Fri) by andfarm (subscriber, #61973) [Link]
No, Rice's theorem only stipulates that you can't make a box that'll compare a Java program and a Javascript program for equivalence. There are any number of ways to convert one to the other -- the most trivial being to write a Javascript interpreter in Java with the source of the JS application embedded in it.
Humphrey: Experiments with audio, part X Posted May 28, 2010 19:25 UTC (Fri) by HelloWorld (guest, #56129) [Link]
You're right, what was i thinking... But nevertheless translating a program to Java that way won't give you more optimization opportunities, which makes the point moot.
Humphrey: Experiments with audio, part X Posted Jun 2, 2010 17:24 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
"won't give you more optimization opportunities, which makes the point moot."
I'd say rather than it makes my point absolutely crystal clear. Your program is now Java, and so the optimisation opportunities are exactly the same. But it may be that with the _exact identical behaviour_ of the Javascript code, there is no additional optimisation possible.
So what screwed up your optimisation wasn't Javascript, but the type of program people wrote in it.
I thought my example with typed vs untyped variables made that pretty clear, but it seems that it got lost in the enthusiasm to invoke Rice's theorem...
Let's take another example: The conventional "Hello, world." in C uses printf() which is a variadic function and a rather complicated one. But to just output a fixed string C provides another function which might be better optimised. Should we blame the C language for the poor performance (assuming we were dumb enough to benchmark Hello World programs) ?
Humphrey: Experiments with audio, part X Posted May 28, 2010 22:56 UTC (Fri) by tzafrir (subscriber, #11501) [Link]
It doesn't really matter. We know we can write a functionally-equivalent program (given the same input, will provide the same output) in Javascript to that of a given Java program. If you know both languages well enough, you'll be able to do that.
That said, invoking the "Turing machine" model and such is not very useful. That model assumes unlimited memory. It doesn't care about performance penalties of an order of magnitude and more. In real life, we actually care about performance. Even if the CPU is fast enough: making it work less drains the battery less.
Or to rephrase that: http://bash.org/?919561
Humphrey: Experiments with audio, part X Posted May 29, 2010 10:11 UTC (Sat) by HelloWorld (guest, #56129) [Link]
I have nothing to say except that you're absolutely right :)
Humphrey: Experiments with audio, part X Posted May 28, 2010 20:18 UTC (Fri) by drag (subscriber, #31333) [Link]
> ... so to sum up that rambling bit: JavaScript will never be faster than Java unless the Java implementations completely stagnate.
Everything you said is absolutely true, but only given a infinite budget and infinite developer resources .
Of course, if your assuming that, then there is little point in programming with anything other then directly into machine code, since assembly will never be able to match the raw power of programming directly in 0's and 1's.
:)
Humphrey: Experiments with audio, part X Posted May 29, 2010 20:23 UTC (Sat) by DOT (subscriber, #58786) [Link]
The audio experiments from this article are done with typed arrays from <canvas>. According to the article, <canvas> and WebGL provide fixed size typed arrays. As Javascript gains types, it becomes possible to rival Java.
Humphrey: Experiments with audio, part X Posted May 31, 2010 15:44 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Not really.
Java can be _faster_ then the best possible optimized C (barring tricks like self-modifying code) because it can use statistics to dynamically recompile bytecode to native code. HotSpot JVM has some of these features, and sometimes they even work.
JavaScript in general can not be as fast as Java, because it's untyped. TraceMonkey and other JITs try really hard to infere types, but in general it's an unsolvable problem (boils down to the halting problem).
Adding vector operations to JVM is a no-brainer. I did this personally some time ago (Neon operations implemented as 'magic' functions treated specially by JIT). Also, LLVM has a pretty good approximation of cross-platform vector operations which can be used as a model.
Humphrey: Experiments with audio, part X Posted Jun 1, 2010 12:38 UTC (Tue) by DOT (subscriber, #58786) [Link]
If I understand correctly, Javascript is gaining types with <canvas> and WebGL. It's not too difficult to imagine why they introduced typed arrays for that element; those operations need to be fast. The audio experiments in the article convert the audio into a canvas array like this: http://scotland.proximity.on.ca/dxr/tmp/audio/tts/phonems...
Humphrey: Experiments with audio, part X Posted May 29, 2010 9:58 UTC (Sat) by roc (subscriber, #30627) [Link]
Check out the numbers here:
https://bugzilla.mozilla.org/show_bug.cgi?id=490705#c49 For this FFT code, JS is within 2x of C. If you don't believe the numbers, you can benchmark the code yourself.
Anyway it doesn't matter how fast JS code runs relative to whatever other language. The important thing here is that JS is fast enough for this task.
Humphrey: Experiments with audio, part X Posted May 29, 2010 15:24 UTC (Sat) by kirkengaard (subscriber, #15022) [Link]
Whose FFT is faster misses the point. Language bikesheds aside, this is really cool work! They got text-to-speech to work with no browser plugins.
Humphrey: Experiments with audio, part X Posted Jun 12, 2010 3:38 UTC (Sat) by nlucas (subscriber, #33793) [Link]
One thing no one talks about is that any CPU intensive application on modern systems must be really worth it or the user will hate it.
Does no one hates it when the computer fan starts running at full speed for no apparent reason?
Whenever I ear it (on my old Pentium D @ 3.4 GHz, which is NOT silent on those occasions) I always have to know what the hell is running that needs so much processing power.
FFTs are not CPU intensive on modern CPUs, but I bet they will be if running on JavaScript.
|
|||||||||||||
