WebAssembly: The new platform the scene needs?
category: code [glöplog]
Quote:
This sobel implementation is truly suspicious. It's like somebody is ruining the performance on purpose (not to mention writing bad code on purpose), and strangely on both ends (C and JS). Trivia: this "great" code is licensed from some dude and used under permission, so yeah, it's like big wtf
Also: Writing to the destination array just for overwriting it afterwards. Makes sense!
Back to topic: So far this WebAssembly looks like Java bytecode reinvented with an even more awkward wrapper around it.
Quote:
Also: Writing to the destination array just for overwriting it afterwards. Makes sense!
Yeah,outstanding example of cargo cult / copy pasting job. Funny.
For WebAssembly and Java VM: looks similar,yes. It's kind of disappointing they have plans to add garbage collector into it. That ain't really assembly then. If they want to support C# really,then they should make it possible to compile GC as a library not a must-have feature.
gasman: Cool! If an accomplished demoscener like you knows nothing about GPUs, lil ol' me still has a shot! :) Hey - got an email address? I'd like to chat with you by email.....
Maybe you guys want to stop bitching about the sobel effect and submit a PR with the right code?
https://github.com/JasonWeathersby/WASMSobel
https://github.com/JasonWeathersby/WASMSobel
mrdoob: it's almost as bad idea as helping a bully in the class with his homework.
tomkh: You're not helping the bully, you're helping everyone that will use his code as reference.
mrdoob: I just found a metaphor, but I didn't mean _he_ is a bully. He might be actually some really cool guy. The thing is, he has to fix his "shit". That's a general principle.
Also, I wouldn't worry if someone will use this code as a reference. Just because it's on MDN? People should learn that there are no authorities ;) otherwise they could be easily deluded by words of some self-proclaimed gurus and/or community celebrities, and actually that happens way too often.
Also, I wouldn't worry if someone will use this code as a reference. Just because it's on MDN? People should learn that there are no authorities ;) otherwise they could be easily deluded by words of some self-proclaimed gurus and/or community celebrities, and actually that happens way too often.
I'm getting really tired of people saying javascript is shit just because they(and 95% of web developers) don't know how to write efficient code with it... Yes its not as fast as native code, and it never will be simply due to the fact that its a dynamic language. I'm probably on a lost cause here but dynamic languages have their own set of merits that allow very elegant solutions to problems you'd have a hard time solving(in an elegant way) in static languages, while I think that this should be obvious this is a whole different discussion I'm not getting into right here.
Back to that writing efficient javascript thing:
Set aside the fact that the sobel filter implementation is flawed and that operations like this would be better implemented on the GPU anyway, I just took a few minutes and optimized the javascript implementation of it(without changing any logic or any signatures) and saved a nice 32ms execution time over the original 80ms. If I were to use webworkers(threading) I could easily beat the webassembly implementation... so go figure.
Nothing "sane" about a library providing a gazillion ways to format dates...
Well apparently you're not prepared...
Back to that writing efficient javascript thing:
Set aside the fact that the sobel filter implementation is flawed and that operations like this would be better implemented on the GPU anyway, I just took a few minutes and optimized the javascript implementation of it(without changing any logic or any signatures) and saved a nice 32ms execution time over the original 80ms. If I were to use webworkers(threading) I could easily beat the webassembly implementation... so go figure.
Quote:
When you need a library that's 20k compressed to have sane date formatting
Nothing "sane" about a library providing a gazillion ways to format dates...
Quote:
I'm prepared to reinvent as many wheels and shave as many yaks as I damn well need to. [...]
Javascript is shitty at interfacing with OpenGL
Well apparently you're not prepared...
Quote:
mrdoob: it's almost as bad idea as helping a bully in the class with his homework.
You really got it wrong with who the bully in this story is.
Quote:
You really got it wrong with who the bully in this story is.
Who is the bully in this story?
Quote:
Quote:When you need a library that's 20k compressed to have sane date formatting
Nothing "sane" about a library providing a gazillion ways to format dates...
If you ever wrote frontend JS for sites, it's one of the problems that'll hit you very very fast. JS' own Date class fails miserably on that end. The same thing is true about 90% of what jQuery and the likes provide - all of it should be part of the JS runtime library implemented natively.
So people have finally realized that the solution is 100% ASM! However, they seem to be doing it wrong. :(
Also: LULZ TAHT SOBELFILTER SO 14M3!!
Also: LULZ TAHT SOBELFILTER SO 14M3!!
Quote:
dynamic languages have their own set of merits that allow very elegant solutions to problems you'd have a hard time solving(in an elegant way) in static languages
"Dynamic typing: The belief that you can't explain to a computer why your code works, but you can keep track of it all in your head."
Anyway, I guess we got distracted by this sobel fiasco.
WasmExplorer looks pretty good on the other hand.
WasmExplorer looks pretty good on the other hand.
Quote:
If you ever wrote frontend JS for sites, it's one of the probl ems that'll hit you very very fast.
I did front end primarily for 4 years(shop systems, galleries, social network like sites and everything inbetween) and never ran into it to a degree that would justify using an external library. Maybe I'm missing a moon calendar project ;)
Quote:
The same thing is true about 90% of what jQuery and the likes provide - all of it should be part of the JS runtime library implemented natively.
It already is, assuming you're not targeting internet explorer versions < 8.
@absence:
dynamic language ⊃ dynamic typing
LJ: improvements in <insert your fav.dynamic language> should not be mutually exclusive with providing additional base layer to support both: static and dynamic approach. If WASM would be true to its principles (multiplatform asm abstraction), you should be able to compile any language to it. That's why I am a bit surprised with this garbage collector plans. Maybe they are just plans and they will abandon them,or at least make it optional.
tomkh: You're right, however as I understood it you can compile anything to WASM, its just that the initial "here's webassembly" package only comes with C/C++, according to their api design document they do want to support other languages. Also maybe I missed something but I've read nowehere that webassembly aims to implement garbage collection, according to their design documents they want give you access to it, so you can interface with it.
LJ: ok,so it looks like they mean something more elaborate when they say "Native GC". I need to read more about this,but at a first glance looks like a generic handling of GC objects that is indeed optional to linear memory model.
Quote:
I did front end primarily for 4 years(shop systems, galleries, social network like sites and everything inbetween) and never ran into it to a degree that would justify using an external library. Maybe I'm missing a moon calendar project ;)
I ran into it as soon as I had to display a date according to a certain format - as soon as you're forced to cobble it together from GetMonth()-s and padding functions you wrote yourself, something went horribly wrong somewhere, not to mention the string-to-date parser varies between Chrome and Firefox, etc. Again, this is a mundane example, but there's a plethora of things missing that people had to add themselves (even when it comes to DOM traversal).
Quote:
It already is, assuming you're not targeting internet explorer versions < 8.
That argument is seriously undercut by the fact that jQuery still exists.
Quote:
not to mention the string-to-date parser varies between Chrome and Firefox
This is and most other things are platform fragmentation problems, not language problems.
Quote:
That argument is seriously undercut by the fact that jQuery still exists.
The only reason jQuery is still used in projects is that most developers don't care and there still being customers demanding support for arcane browsers. You thinking that 90% of what jQuery and the likes provide not being already part of JS runtime library makes you one of these developers so does dropping a library like momentjs on a simple "i want my date to look like this" problem. How many different ways do you need to display your date? Most probably only 2-3 so whats the matter of just writing the 10ish lines to get the job done? This is the exact reason why web developers have such a bad rep, because apparently "nobody gives a shit so lets just drop 10 libraries and write some glue" seems to be the norm.
As to working with the DOM:
You never heard of the querySelector interface did you? Modifying attributes using setAttribute,getAttribute and removeAttribute?Adding and removing classes using classList? Getting proper element position information using getBoundingClientRect?
Now tell me what does jQuery provide that's not already part of modern JS core? The only thing coming to mind would be the simplified ajax request interface(get,post,load), which in turn is just a micro shim on top of its inbuild 'ajax' method which is a behemoth of fuzzy argument detection(just like the rest of jQuery) and when called directly turns out to be more code than just doing your own XMLHttpRequest in most cases, not to mention that Fetch API is coming to your rescue here if you feel like doing XMLHttpRequests is too complicated.
Your miles away from my point. I'm not against rolling your own code, in practice - I'm forced to do it because I'm sure as hell not going to use a 20k library for a date formatting. We're on the same page here.
My point is these libraries shouldn't even exist, because the services they provide should be part of the common JS runtime, and they're not.
My point is these libraries shouldn't even exist, because the services they provide should be part of the common JS runtime, and they're not.
No I'm not, I just showed you that most of it already is part of common JS runtime(so is sane date formatting), the fact that library features are migrated into the core just doesn't make the libraries disappear. If you're vouching for "they should've implemented all of it in the beginning" then thats simply not how software development and platform evolution works(see OpenGL and its extensions as native code example).
what LJ said.
tomkh: please stop trolling
Gargaj: why would they want to complexify the core when there are tons of libs to solve those problems? lazy programmers include the libs, the optimizer programmers roll their own or copy paste a function from stackoverflow. for the record i agree the date functionality on js is wonky.
tomkh: please stop trolling
Gargaj: why would they want to complexify the core when there are tons of libs to solve those problems? lazy programmers include the libs, the optimizer programmers roll their own or copy paste a function from stackoverflow. for the record i agree the date functionality on js is wonky.
