|
in before the meaningful mention that metal is multi-platform also supporting known heavyweight game seller "the mac"
|
#
?
May 4, 2018 00:53
|
|
|
|
| # ? May 20, 2024 10:33 |
|
|
Notorious b.s.d. posted:
please name another platform or api where this is true
|
|
#
?
May 4, 2018 01:14
|
|
|
Spent a good portion of today trying to get bits and pieces of my model-viewer ported to WebAssembly, namely the slow bits that are done during scene setup (Yaz0 decompression, image deswizzling and decoding, vertex loading). The end result is about 2x slower than the JS JIT. I tried both a gcc-powered version, and then tried a hand-written version -- both were slow. I'm not using any glibc. These are "DSP" like functions which have a src buffer and a dst buffer and just do some sort of large transformation that's mostly buffer copies, so you would think it would be a slam-dunk for WASM where I would get predictable and tight "inner loop" performance but nah it can't even do that correctly. Firefox tells me I'm on a "slow entry trampoline" but not why, so I'm on some sort of slow path already for unknown reasons -- the source code suggests that trying to use SIMD causes the WASM not to be JIT-compiled (???) but I'm not using anything SIMD. Somehow according to the profiler I'm also spending a 0.5s in the GC. I *do* have to create a large linear heap for the WASM to run in (it's impossible rn to specify two separate heaps which would be super helpful since I can pass the src/dst buffers in separately) so there's two memcpy's instead of zero, but somehow it adds up to 0.5s of GC. I'm allocating 8MB of short-lived heap objects, which, sure, is a lot, but these things aren't going to be moving around (they don't live outside the function so they should be super quick to free in the short-lived arena), and they aren't growing while the WASM is running, so how a browser can spend 0.5s GCing in here bewilders me. So, yeah. Basically exactly the wet fart in terms of performance I expected, with half-assed implementations that interact poorly with the JS interpreter. It's probably a win if you're Google and your cross-compiled browser Java inexplicably already takes 5 seconds to show a text-only email. The next generation in web development is here.
|
|
#
?
May 4, 2018 08:32
|
|
|
pokeyman posted:also supporting known heavyweight game seller "the mac" https://www.youtube.com/watch?v=37YY25vvYho&hd=1
|
|
#
?
May 4, 2018 13:55
|
|
|
Suspicious Dish posted:half-assed implementations seems about right for webdev, then?
|
|
#
?
May 4, 2018 15:18
|
|
|
Suspicious Dish posted:Spent a good portion of today trying to get bits and pieces of my model-viewer ported to WebAssembly, namely the slow bits that are done during scene setup (Yaz0 decompression, image deswizzling and decoding, vertex loading). The end result is about 2x slower than the JS JIT. I tried both a gcc-powered version, and then tried a hand-written version -- both were slow. I'm not using any glibc. 
|
|
#
?
May 4, 2018 17:11
|
|
|
i dont follow webass too closely so I don't know what kind of deployment status its at, but... i thought it was not at a "this thing is done, use it and go wild" stage yet? last i read they were still in heavy development on js interop and lots of other important pieces of it also js engines have got 2 decades of work behind them so im not terribly surprised that some tyupes of JITed code are fast on the other hand, it's not really clear why what your'e doing is slow. have you submitted an issue to firefox/chrome/anywhere? I'd be really interested in following that
|
|
#
?
May 4, 2018 17:26
|
|
|
Is this a dumbass opinion? If WASM could be used to get at rowhammer or specter like behaviors then I'd be shocked if it didn't get hit with a big, intentional performance penalty, hitting it smack dab in the kind of functions that it "should be good at".
|
|
#
?
May 4, 2018 17:33
|
|
|
that’s true of javascript, too. all these untrusted-code platforms have to sacrifice some performance to resist that kind of attack
|
|
#
?
May 4, 2018 17:41
|
|
|
Thermopyle posted:i dont follow webass too closely so I don't know what kind of deployment status its at, but... Yeah, I wasn't expecting tremendous gains, it was more an idea about "here's a small task I can try to see what it can do" and I came away underwhelmed. It certainly *works*, and that's really cool. I'm chatting with the Firefox guys about it and they're helping me which is cool. It definitely seems to be GC overhead, rather than WASM overhead -- once the WASM runs, it runs pretty fast. Experiment here: https://github.com/magcius/model-viewer/commit/02ff7a1c093282534a0386da817487fd91e851e9 Profiler breakdown:  The little green "..."s are the actual execution -- GC seems to happen before we even run the code, and massively, too. I don't know why. Suspicious Dish fucked around with this message at 17:53 on May 4, 2018 |
|
#
?
May 4, 2018 17:50
|
|
|
just yesterday some guys released a proof of concept rowhammer implementation that used drive by JS Web GL code to execute arbitrary code on a Nexus 5 android phone
|
|
#
?
May 4, 2018 18:02
|
|
|
Suspicious Dish posted:I wasn't expecting tremendous gains I've found lean protein helps a lot in this regard,
|
|
#
?
May 4, 2018 18:14
|
|
|
prisoner of waffles posted:Is this a dumbass opinion? If WASM could be used to get at rowhammer or specter like behaviors then I'd be shocked if it didn't get hit with a big, intentional performance penalty, hitting it smack dab in the kind of functions that it "should be good at". didn't the spectre paper have a js implementation? not really specific to webass
|
|
#
?
May 4, 2018 18:20
|
|
|
prisoner of waffles posted:Is this a dumbass opinion? If WASM could be used to get at rowhammer or specter like behaviors then I'd be shocked if it didn't get hit with a big, intentional performance penalty, hitting it smack dab in the kind of functions that it "should be good at".
|
|
#
?
May 4, 2018 18:21
|
|
|
Thermopyle posted:just yesterday some guys released a proof of concept rowhammer implementation that used drive by JS Web GL code to execute arbitrary code on a Nexus 5 android phone lol, that's probably why chrome disabled ext_disjoint_timer_query with no explanation a few months ago then
|
|
#
?
May 4, 2018 18:33
|
|
|
mystes posted:I think the main mitigation in JS so far was just limiting timer resolution, but maybe there will be more in the future. they also disabled sharedarraybuffer because it turned out that incrementing a number in a loop in another thread is a good enough timer to do spectre shenanigans
|
|
#
?
May 4, 2018 18:41
|
|
|
wish they’d disable javascript altogether. hypertext documents have no business performing execution period, let alone speculative execution.
|
|
#
?
May 4, 2018 19:07
|
|
|
Soricidus posted:wish they’d disable javascript altogether. hypertext documents have no business performing execution period, let alone speculative execution. shaggar alt spotted
|
|
#
?
May 4, 2018 19:07
|
|
|
akadajet posted:shaggar alt spotted
|
|
#
?
May 4, 2018 19:14
|
|
|
repiv posted:lol, that's probably why chrome disabled ext_disjoint_timer_query with no explanation a few months ago then thats exactly why
|
|
#
?
May 4, 2018 19:16
|
|
|
akadajet posted:eschaton alt spotted
|
|
#
?
May 4, 2018 19:45
|
|
|
c tp s: new intern started working this week. he was the first guy to see my current project's f# codebase so I'd spend the previous few days cleaning it up, adding comments, and most importantly replacing some of the fancier tricks i used with more verbose but simpler code turns out he's a haskell turbonerd who goes on nerdgasma talking about catamorphisms and quasiquotations  git reverted immediately and brought back all the srtp goodness
|
|
#
?
May 4, 2018 20:23
|
|
|
NihilCredo posted:c tp s: new intern started working this week. he was the first guy to see my current project's f# codebase so I'd spend the previous few days cleaning it up, adding comments, and most importantly replacing some of the fancier tricks i used with more verbose but simpler code hire him but oh boy do i ever feel you about self policing your fancy fp junk. of course at my level it's more like "hey ya'll maybe we should use Either instead of throwing exceptions everywhere" and everyone bitches about having to learn a new pattern. which i totally get. so our code base is bad. DONT THREAD ON ME fucked around with this message at 21:15 on May 4, 2018 |
|
#
?
May 4, 2018 21:09
|
|
|
put a ring on it
|
|
#
?
May 4, 2018 21:13
|
|
|
Soricidus posted:wish they’d disable javascript altogether. hypertext documents have no business performing execution period, let alone speculative execution. delenda est JavaScript
|
|
#
?
May 4, 2018 21:50
|
|
|
NihilCredo posted:c tp s: new intern started working this week. he was the first guy to see my current project's f# codebase so I'd spend the previous few days cleaning it up, adding comments, and most importantly replacing some of the fancier tricks i used with more verbose but simpler code Quasiquotations and Template Haskell are abominations. All languages turn into C++ eventually.
|
|
#
?
May 4, 2018 22:24
|
|
|
Athas posted:Quasiquotations and Template Haskell are abominations. quasiemptyquoting
|
|
#
?
May 4, 2018 22:45
|
|
|
Suspicious Dish posted:please name another platform or api where this is true opengl and friends are the obvious choice (i'm sure you have some elaborate rationale for why that's not a thing, and i get that. you could have just started out with the effort post on opengl)
|
|
#
?
May 5, 2018 02:48
|
|
|
MALE SHOEGAZE posted:quasiemptyquoting
|
|
#
?
May 5, 2018 03:03
|
|
|
repiv posted:they also disabled sharedarraybuffer because it turned out that incrementing a number in a loop in another thread is a good enough timer to do spectre shenanigans It's bizarre to me, because using SharedArrayBuffer and a Web Worker to build a high-resolution timer was known in 2015, along with a handful of other techniques you could use, and decided that it was not important enough to lock down. In my WebAudio exploration, the follow-up messaging was clear: "use SharedArrayBuffer together with an AudioWorklet for garbage-free audio output". But that path seems to be closed now, with no clear timing on when it will be available again. Web platforms are messy, sure, but browser vendors holding you to the fire and removing features that are bedrock for future stuff just makes me really upset. For now, I'll go back to figuring out WASM is triggering that GC. Have a great weekend, folks.
|
|
#
?
May 5, 2018 03:44
|
|
|
Notorious b.s.d. posted:opengl and friends are the obvious choice They're not the obvious choice. Platforms that support OpenGL as a first-class citizen: Windows (using NVIDIA), Android, and Linux. Oh, and the web, I guess (unless you're on an iPhone). Platforms that use Vulkan has their own preferred graphics abstraction API: Android, and Linux Kind of supports OpenGL but crashy and vendors laugh at you if you actually use it: Windows (using AMD or Intel), Mac, PS3, and Switch. Platforms that have their own preferred graphics abstraction API: Windows and Xbox One (Direct3D), Mac and iOS (Metal), PS4 and Vita (libgnm), Switch (NVN), 3DS (DMP). Did I forget any? You can't take an OpenGL game and port it to Xbox One without redoing your graphics stack. You also can't take an OpenGL game and port it to iOS without redoing your graphics stack. Why is that a problem?
|
|
#
?
May 5, 2018 03:49
|
|
|
Suspicious Dish posted:Web platforms are messy, sure, but browser vendors holding you to the fire and removing features that are bedrock for future stuff just makes me really upset. browser vendors should remove progressively more features so that people will stop trying to cram apps into web pages I’m not kidding or being ironic when I say this, I honestly think it would be the best possible thing for users and developers to create real applications with platform native UI and stop cramming everything through the browser delenda est JavaScript
|
|
#
?
May 5, 2018 04:08
|
|
|
Suspicious Dish posted:Kind of supports OpenGL but crashy and vendors laugh at you if you actually use it: Mac, PS3 to further elaborate, mac supports opengl only in the sense that they haven't ripped it out yet. osx supports opengl 4.1, which is 8 years out of date and doesn't even support compute shaders. opengl is absolutely the wrong choice for any new work targeting osx. to say that the ps3 supported opengl is a real stretch. it supported psgl, which was a sort-of opengl es 1.0 with some extensions that was really bad and slow since everything involved an extra level of indirection which caused the already slow processors in the previous console gen to stall even more than they already did. you didn't get glsl support either, just cg. it seemed more like an experiment than something someone would actually want to use.
|
|
#
?
May 5, 2018 04:49
|
|
|
I only mention it because my employer shipped games using PSGL. A heavily modified version of PSGL, mind you, but still PSGL. The renderer was really simple up until a few years ago. The PS3 architecture was really terrible for games just in general but that's a story for another thread.
|
|
#
?
May 5, 2018 04:59
|
|
|
eschaton posted:browser vendors should remove progressively more features so that people will stop trying to cram apps into web pages Sure, but only if they improve the developer experience on Mac to not be loving terrible. Seriously, use some of that 36 billion dollars or whatever you have lying around, buy some PS4 SDKs made by grownups and call me back when you can do a twentieth of the stuff they have.
|
|
#
?
May 5, 2018 05:02
|
|
|
so ah what's the other platform for hardware-independent net-delivered interactivity that we're all missing out on?
|
|
#
?
May 5, 2018 06:18
|
|
|
from the standpoint of users the web is the best application delivery platform that has ever existed
|
|
#
?
May 5, 2018 06:33
|
|
|
eschaton posted:browser vendors should remove progressively more features so that people will stop trying to cram apps into web pages my friend, you were alive and working in the days when Microsoft ruled the computing landscape with an iron fist and I don't think anybody wants to return to them maybe in ten years when Linux might not be a completely dickless opposition (desktop environments were a solved problem ten years ago, surely they will eventually get bored of endlessly rewriting their broken poo poo from scratch), because Apple's focus on the wealthiest 10% sure as hell ain't gonna be it.
|
|
#
?
May 5, 2018 06:37
|
|
|
i mean it sounds funny now, sure, but ten years ago desktop linux was on the cusp of actually becoming a credible (albeit slightly niche) desktop computing platform. people were actually sort of starting to take the platform seriously even. all they had to do was basically hold a steady course and not gently caress it up. lol (tbf though that was also roughly the point at which smartphones happened and that just made a horrible mess out of everything)
|
|
#
?
May 5, 2018 06:41
|
|
|
|
| # ? May 20, 2024 10:33 |
|
|
maybe, maybe 3DUI has the potential to disrupt the status quo enough for a platform to emerge independent of the web, but no significant number of developers want to return to managing a UI with a friggin WindowProc
|
|
#
?
May 5, 2018 06:47
|
|