What are some experiences with asm js

asm.js, progress to regression

  1. Forums
  2. > Comments
  3. ›Software development
  4. ›All comments on the article
  5. ›Monster Madness: First ...
  1. theme

New topic Change view


  1. asm.js, the progress towards regression

    Author: twothe 13.12.13 - 12:56

    That someone actually had the stamina to make a whole game in asm.js is admirable, but I think it is improbable that this catches on. First of all, some basic information, since the half-knowledge is again circulating wildly.

    asm.js is not a miracle and not a fundamentally new technology, it only reduces the JavaScript language set to a very small part, which - after successful validation - can be directly translated 1: 1 into native code. The advantage is obvious at first, because the performance increases significantly. Up to 50% of "real" native code is included, but the advantage that such asm.js code delivers very stable performance, which means that it can also be debugged well.

    The disadvantage is that the programmer has to bypass the first compilation step, so that no unnecessary interpretation of the code is necessary. Since this not only eliminates many language constructs, but also has to use special constructs for an exact notation, the code result is reminiscent of something between the good, old assembler and Brainfuck. An example:

    function f (x, y) {
    // SECTION A: parameter type declarations
    x = x | 0; // int parameter
    y = + y; // double parameter

    // SECTION B: function body
    log (x | 0); // call into FFI - must force the sign
    log (y); // call into FFI - already know it's a double
    x = (x + 3) | 0; // signed addition

    // SECTION C: unconditional return
    return ((((x + 1) | 0) >>> 0) / (x | 0)) >>> 0; // compound expression
    }

    function h (i, x) {
    i = i | 0;
    x = x | 0;
    H32 [i >> 2] = x; // shifted by log2 (byte count)
    ftable_2 [(x-2) & 2] (); // dynamic call of functions in table 2
    }

    While the first part is still in the "unfamiliar" area, the lower part should make it clear what you are getting into. Clear or understandable code is the exact opposite, and I feel sorry for anyone who has to debug it. Thanks to modern technology, you are effectively back where you were 10 years ago: optimize using assembler, because the system is too slow to execute understandable code quickly enough. Only that we are talking about 4 GHz systems today, and no longer 0.4 GHz.

    If you are forced to use JS in your browser for some reason for any project, ok: then asm.js is a good thing. But if not, keep in mind that debugging is a large part of programming, and the more complicated the code, the longer it will delay delivery (and thus increase project costs).

    Asm.js is all possible, but certainly not the savior for the browser. One can rightly ask oneself: if we have to go back so far in the development of programming that we are back to assembler in order to achieve decent performance, that does not mean, conversely, that the technology we are trying to use is actually completely unsuitable ? My favorite language LUA, for example, achieves the same performance with LUAJit, but with completely readable and easy-to-maintain code without having to restrict yourself in any way.

    If asm.js tells me anything, it's just that it is high time to turn away from this JavaScript nonsense and instead work on the diffusion of a more meaningful technology. Fortunately, Google is already on with darts.

  2. Re: asm.js, progress to regression

    Author: superhans 13.12.13 - 14:40

    But you already realize that they don't write JS code themselves, but have their C ++ code translated into Js?
    Well, I'm assuming that it was the same here.

    If there are problems and you need to debug them, of course you are right.

  3. Re: asm.js, progress to regression

    Author: Paykz0r 13.12.13 - 14:41

    ASM.JS is a compiler target if you will.

    you don't write that by hand and that's not what it's intended for,
    to make it short.

    The Unreal Engine was ported accordingly.
    The game there was written in C / C ++ and then together with the Unreal Engine
    converted to ASM.JS by Ecmascripten.

    Personally, I don't understand what you are against or why javascript should be abolished. is not a compulsion. get noscript and surf with it.
    nobody blames you.
    but don't try to prevent the world from using javascript.
    these are approaches from java web start and flash away.
    this can ensure greater security and a more open web.
    I am excited about it.

  4. Re: asm.js, progress to regression

    Author: daZe 13.12.13 - 14:54

    > but don't try to prevent the world from using javascript.
    > these are approaches from java web start and flash away.
    > this can ensure greater security and a more open web.
    > I am excited about it.

    Typical statement from a technology troll (do you use Apple products? :-).
    What the poster says is that such JS developments "technically" (!!) represent a step backwards and I can only strongly agree with this statement. Anyone who, like you, writes nonsense like "great the Flash is gone" or "great open web" has never tried to write more complex programs in JS (or to finance them as a donor). JS is and remains a (heavily pimped) but basically "ugly script language" which is unreasonable even without optimized code (as far as the code image is concerned).

  5. Re: asm.js, progress to regression

    Author: superhans 13.12.13 - 15:00

    JS is an ugly language that lacks some of the higher features needed to write large applications. It is not for nothing that there are a thousand frameworks. It will get better with the next version (finally modules), but it won't be much nicer either. There is a YouTube video in which the "funniest" design errors are summarized, but unfortunately I can't find it at the moment :(

    Edit: Found it! https://www.destroyallsoftware.com/talks/wat



    Edited 1 time, last on 13.12.13 15:08 by superhans.

  6. Re: asm.js, progress to regression

    Author: Paykz0r 13.12.13 - 15:08

    daZe wrote:
    --------------------------------------------------------------------------------
    >> but don't try to prevent the world from using javascript.
    >> these are approaches from java web start and flash away.
    >> this can ensure greater security and a more open web.
    >> I am excited about it.
    >
    > Typical statement from a technology troll (do you use Apple products? :-).
    > What the poster says is that such JS developments "technically"
    > (!!) represents a step backwards and I can only strongly say this
    > agree. Anyone who, like you, nonsense á la "great the Flash is gone" or
    > "Great open web" writes, has never even tried more complex
    > Writing (or funding) programs in JS. JS
    > is and remains a (heavily pimped) but basically "ugly" one
    > Script language "which is unreasonable even without optimized code (what that
    > Code picture concerns) represents.

    you are completely wrong.
    I have been working as a pure JavaScript frontend developer for almost 4 years,
    also for very well-known customers.
    Before that, I wrote Nintendo DS games in C / C ++ for 3 years.

    To be able to combine the two soon is a real hammer and absolutely not a step backwards. And don't guess whether I have a clue or not just because I say I want an open web.

    But I can expand on what I mean.
    I've lived through both worlds professionally. Hardware-related C / C ++ on a 33Mhz device
    3d Games Developed,
    and suddenly switched to a pure Javascript application developer.
    Another great thing, but a completely different world.
    A clean software architecture was much more important, because the web apps always have to be maintained. At DS games, a flawless version was virtually irrelevant after the release. The main thing is that the partial depth runs smoothly on the special hardware.

    Well, you can now develop really nice and clean under JS.
    You can bsw. look at ExtJS / Angular etc.

    But what has been missing so far is the hardware-related options.
    Not just for games. This can also be used for control systems, home control systems, etc.
    what is happening here will be of great benefit.
    And I say that from experience, I am also active in these sectors.
    Conceivable would be NodeJS servers that run on all possible devices with webser,
    and you can go on it from the outside (in the same wifi) with the browser (pc / tablets, etc.) and thus control everything centrally.
    Everything from a single source.

    Backend in JS, frontend in JS ... with the help of Grunt you can even do the build processes and the deployment etc everything in JS.
    In addition, there are ASM.JS modules that serve as hardware drivers and then it works properly.



    Edited 1 times, last on 13.12.13 15:12 by Paykz0r.

  7. Re: asm.js, progress to regression

    Author: Paykz0r 13.12.13 - 15:15

    superhans wrote:
    --------------------------------------------------------------------------------
    > JS is an ugly language that lacks some higher level features to order
    > write large applications. It is not for nothing that there are a thousand frameworks.
    > It will get better with the next version (finally modules), but a lot
    > It doesn't make it more beautiful either. There's a youtube video in that
    > The "funniest" design errors are summarized, I think
    > but unfortunately not :(
    >
    > Edit: Found it! www.destroyallsoftware.com

    There is the following under the video:
    "The sarcasm in this talk does not represent anyone's actual opinion. For a more serious take on software, try Destroy All Software Screencasts: 10 to 15 minutes every other week, dense with information on advanced topics like Unix, TDD, OO Design, Vim , Ruby, and Git. "

    The video is funny, no question about it.
    But comes from people who like to work with these technologies.
    That's just sarcasm ...

  8. Re: asm.js, progress to regression

    Author: superhans 13.12.13 - 15:19

    Sure, but it doesn't change the fact that these are problems with the language: D
    Every language has its problems, including Javascript. But as I said, there are reasons why there are thousands of frameworks and also languages ​​that compile according to Javascript (CoffeeScript, TypeScript, Dart, etc.pp).

  9. Re: asm.js, progress to regression

    Author: Paykz0r 13.12.13 - 15:27

    superhans wrote:
    --------------------------------------------------------------------------------
    > Sure, but it doesn't change the fact that these are language problems: D
    > Every language has its problems, including Javascript. But how already
    > Said there are reasons why there are thousands of frameworks and also
    > Languages ​​that compile according to Javascript (CoffeeScript, TypeScript, Dart,
    > etc.pp).

    Yes,
    in any case.
    There are crazy funny things that really take getting used to.
    If you look at a truth table what is true or false in Javscript, it starts. But that bsw. takes a Coffecript etc. unfortunately not everything.

    There are definitely some pitfalls
    but on the other hand there are some really brilliant things that only work with such languages. And apart from that: you can change almost everything in JS that doesn't fit!
    Whether that is recommendable is another question, but the language is so dynamic and adaptable ... That requires real rethinking when you bsw. previously done C / C ++.
    As I said, I like both sides.
    Has all advantages and disadvantages.
    C also has some ugly things to offer,
    Java just like that. I cannot judge other languages.

  10. Re: asm.js, progress to regression

    Author: twothe 13.12.13 - 16:17

    Paykz0r wrote:
    --------------------------------------------------------------------------------
    > The game there was written in C / C ++ and then together with the Unreal
    > Engine converted into ASM.JS by Ecmascripten.

    That is correct, but does not change anything in my statement. Another compile target is nice, but says at the same time: "Don't program anything complex in JavaScript". This compiler was invented for exactly such a reason, and for the same reason one generally no longer programs in assembler these days.

    What bothers me a lot are actually these JavaScript evangelists who say: "JavaScript is great and thanks to asm.js also incredibly fast!" It should correctly read: "JavaScript is so slow that asm.js had to be invented to keep it running reasonably quickly."

    It's a bit like when you want to hit the autobahn with an old duck. That only works if you strap a second car to the front that pulls you. Now of course it's fun to drive such an old duck, and I would probably do it for the gag too, but if I think realistically and efficiently, then I should leave the duck in the garage and drive the pulling car instead. The problem for me is the people who tell me that a duck is actually the best car there is, and even incredibly fast ... if you cling a Porsche to the front. Then I always lack a bit of understanding.

    With this profound symbolism ... have a nice Friday. ;)

  11. Re: asm.js, progress to regression

    Author: Paykz0r 13.12.13 - 18:34

    twothe wrote:
    --------------------------------------------------------------------------------
    > Paykz0r wrote:
    > ---------------------------------------------------------------------------
    > -----
    >> The game there was written in C / C ++ and then along with the
    > Unreal
    >> Engine converted into ASM.JS by Ecmascripten.
    >
    > That is correct, but does not change anything in my statement. Another one
    > Compile-Target is nice, but at the same time says: "Better program
    > Nothing complex in JavaScript ". Because this is exactly the reason for this
    > Compilers have been invented, and programming is done for the same reason
    > Generally not in assembler these days.
    >
    > What bothers me a lot are actually these JavaScript evangelists
    > say: "JavaScript is great and, thanks to asm.js, also incredibly fast!" There
    > It should read correctly: "JavaScript is so slow that asm.js was invented
    > had to be so that it still runs reasonably smoothly. "
    >
    > It's a bit like taking an old duck on the autobahn
    > want. That only works if you strap a second car to the front of the one
    > pulls. Now of course it's fun to drive such an old duck, and me
    > Would probably do for the gag too, but if I was realistic and
    > efficient think then I should leave the duck in the garage and
    > Drive the pulling car instead. The problem for me is then
    > People who then tell me that a duck is actually the best car in the world
    > there is, and even incredibly fast ... if you have a Porsche at the front
    > stuck. Then I always lack a bit of understanding.
    >
    > With this profound symbolism ... have a nice Friday. ;)

    Well, you have to differentiate.
    I know why JS has such a bad reputation.
    There are many reasons for this.
    One is BSW. that Firefox wrote for years with every new version
    the JS has become so and so many percent faster.
    That was also true, but no user noticed anything.
    What was that? For example, if you add an animation to the page,
    Javascript only triggers the CSS / HTML and the animation runs. No matter how fast Javascript runs, the animation runs sometimes jerkily from then on. And that's because of the HTML renderer.
    The other thing that many people criticize JS is browser differences.
    This is also not due to JS as a language. ECMASCRIPT is precisely defined.
    The MS, for example, calls the event listener differently than Firefox,
    the language can't do anything for that.

    Who looks at the purest JS (e.g. server side through NodeJS)
    will find that JS can be very consistent and beautiful.

    Another reason is partly JQuery and its plugins.
    Sometimes they shoot each other out and you're often better off
    things are easy to implement yourself.

    And last but not least:
    JS is only as good as its developers.
    Since most of them originally came from the classic web design somehow
    Becoming a JS developer also has its effects.
    Real programmers who have design patterns on it will really find it
    in very few agencies. And I know what I'm talking about
    I am always rented to such companies and play the fire brigade
    when everything is just snotty shortly before the release.

    And when you see how they work
    Include scripts and do not even know that it is not guaranteed in which order they are loaded, but also build up dependencies there from the ugliest variety, nothing amazes me. Not even your statement,
    you cannot implement complex projects with it.

    But this is not the case.
    You can not only do that,
    Many do that non-stop.
    And with the right frameworks (I can only highly recommend Extjs!)
    you have nothing to do with browser differences.
    In the case of ExtJS, you don't even write html / css.
    You just nest widgets with JSON and add controllers and stores to them.
    And it just works the same way in every browser.

    You can build such high quality stuff there.
    But most of them don't know that and jump into jquery hell.
    But that's not all because of the language.
    As I said, JS has its linguistic pitfalls.
    But that is usually not the problem but rather the ignorance of the developers.



    Edited 1 times, last on 13.12.13 18:36 by Paykz0r.

  12. Re: asm.js, progress to regression

    Author: like 13.12.13 - 18:58

    I am of the opinion that the approach does not reflect the philosophy behind asm.js. It would be better to first mentally say: "Javascript and asm.js are two completely different things."

    asm.js is basically the bytecode of a virtual machine. And that is just as little written directly as bytecode for the JVM, .NET. Instead, almost without exception, a high-level programming language is used and compiled in bytecode.

    A browser that has special support for asm.js also treats such code differently than Javascript code (especially precompilation vs. just-in-time), only that allows the comparatively high performance. The gimmick of the story is that the bytecode presentation has been chosen in such a way that it also represents a valid Javascript program and can therefore also be executed as a makeshift in browsers that do not offer special support for asm.js.

    Personally, I am of the opinion that this idea is less ingenious than it sounds at first and I prefer the introduction of a completely redefined, cross-browser, open and standardized virtual machine. This would have the advantage of not being associated with JavaScript and thus with the said poor performance. The fact that asm.js code can also run on browsers without special support (then potentially with really poor performance) also harbors the risk that this prejudice will even be reinforced by actual user experience. But that is my personal opinion, and I acknowledge that the path chosen will of course lead to an appreciable dissemination more easily. This shows, for example, that PNaCl is indeed a new virtual machine, but has so far not been well received.

    What is currently really catastrophic (at least as far as I know) is the situation with regard to debugging. Since asm.js is only superficially Javascript, a Javascript debugger doesn't help in the least. This is comparable to a Java debugger, which can only display bytecode and only internal system IDs instead of variable names. Without a debugger, which can map the system status back from the browser to the original high-level code, direct development for asm.js targets is practically impossible. That will probably also be the reason why there are mainly only ports so far. The code has been tested and runs on a different platform, and then it is compiled to asm.js and one hopes for the best. If the situation has improved here, one shouldn't like to correct it. ;)

  1. theme

New topic Change view


To comment, please log in or register. You must also go to your account profile under Forum have assigned a username. To the login

© 1997-2021 Golem.de. All rights reserved.