|
Wait how do the asm.js/wasm teams do it in their demos then? I thought they had really smooth complex games running on js, although maybe WebGL does it in a better way?
|
#
?
Mar 24, 2016 21:06
|
|
|
|
| # ? May 4, 2024 23:04 |
|
|
asm.js is a different beast entirely. GC is disabled, there is no access to the DOM, no dynamic type guards, no (auto-)boxed values, plus everything defined in asm.js has a more or less clear compilation path to machine code.
|
|
#
?
Mar 24, 2016 21:19
|
|
|
Hmm, maybe I should have watched the video rather than being an internet person and commenting on something without knowing anything about it.
|
|
#
?
Mar 24, 2016 23:54
|
|
|
I don't really get the gmail being slow thing. Do people really find it that bad aside from startup time? I have a laptop that is a few years old and I've never felt weird about its performance. Come to think of it I don't really have many issues with most sites' performance aside from startup time. edit: I've also never run in to any bugs  edit: The video is weird since it briefly goes in to "Node.js sucks and is bad and also performance on web stuff is horrible" but then also kind of goes in to a different direction of people not caring about quality in software, which is somewhat tangential. He doesn't really address core problems with Node.js, he says Gmail is bad and also Node.js is bad, but the things he brings up about Gmail aren't really about the stack it's running off of (which is probably python on the backend and some bizarro Google framework like GWT still on the front-end) aside from the front-end performance, which I haven't really had issues with but still a valid concern. Analytic Engine posted:Here's a video trashing Node and webdev by Casey Muratori, a guy who contributed to the game The Witness, wrote very popular graphics rendering code, and is making the C++ Handmade Hero project: He's also kind of trashing....most software in general. He doesn't really point to anything js specific but also goes on to say that low software quality is a tradeoff and makes sense for a lot of people, and hell most jobs you're working on will probably fit that bill. piratepilates fucked around with this message at 00:31 on Mar 25, 2016 |
|
#
?
Mar 25, 2016 00:18
|
|
|
Game development is an entirely different world and culture, and sometimes it's cryptic or frustrating to deal with. People are expected to know the math, know the tricks, and learn what a lot of tricky code is doing, all inline. In any modern engine, your audio code or your physics code is likely going to be large amounts of SIMD, optimized to hell and back. I haven't seen one good JS port of a physics engine that doesn't have a giant GC pause after a few frames because every collision generates 200 different objects for the colliding pairs. JIT behavior and performance is unpredictable and undebuggable, and there's no constant set of best practices for how to make your code faster on modern JITs -- there are loads of "magic tricks" which have broken when e.g. Crankshaft comes out and completely blows up by doing a full-hot-compile mid-frame. So, to game developers and demoscene people like Casey and Jonathan Blow, the fact that JS is finally now getting SIMD support in 2016, and it's still really basic MMX poo poo, is laughable. It's amateur hour. JS still doesn't have real large integers (you have to emulate it with pairs of 32-bit numbers)??? How do you build anything with real precision? (answer: you just don't, everything eventually breaks given too large of a number) Emscripten throws the entire thing out and goes "let's emulate the C runtime heap by having a giant loving Uint8Array which we can address", which, hey, it works. You don't get GC pauses, you just get a giant 100MB constant overhead and hope you don't run out. And this is just JS. Let's not get started about how the web platform is complete horseshit where we have five different ways of drawing basic shapes, with different semantics between them, undefined and strange amounts of feature overlap, and of course none of them cooperate in any way.
|
|
#
?
Mar 25, 2016 00:32
|
|
|
I don't use npm, so I don't know the workflow or why people aren't putting their dependencies under source control, but some developer flipped his lid:quote:Koçulu did not take the decision well. "I know you for years and would never imagine you siding with corporate patent lawyers threatening open source contributors," he wrote back. Disillusioned, Koçulu demanded, "I want all my modules to be deleted including my account, along with this package. I dont wanna be a part of NPM anymore. If you dont do it, let me know how do it quickly. I think I have the right of deleting all my stuff from NPM." Which caused a 2 hour period where apparently "thousands" of devs had all their poo poo broken. Hah, I say, serves you all right.
|
|
#
?
Mar 25, 2016 04:34
|
|
|
Suspicious Dish posted:So, to game developers and demoscene people like Casey and Jonathan Blow, the fact that JS is finally now getting SIMD support in 2016, and it's still really basic MMX poo poo, is laughable. It's amateur hour. Thanks SD, this viewpoint is really interesting and I never hear it from webdev & dataviz circles. Are there serious debates on this stuff or weighing of concerns amongst architects and seniors at Goog/etc? To crosspost from YOSPOS, Jon Blow gave a lecture on why webdev "sucks" and how SV is wasting their developer talent. It's pretty inflammatory and not what you usually hear from the mouths of millionaire SV tech people. https://www.youtube.com/watch?v=k56wra39lwA Analytic Engine fucked around with this message at 06:04 on Mar 25, 2016 |
|
#
?
Mar 25, 2016 04:37
|
|
|
I get that game dev consumes single machine resources and requires realtime guarantees that no other branch of software dev really needs, but holy lol if you honestly say they don't output some genuinely buggy poo poo.
|
|
#
?
Mar 25, 2016 04:54
|
|
|
To be fair to garbage collection, gc delays with a continuous collector aren't really any worse or less predictable than the delays you get doing manual heap allocation. There's a reason you don't do heap allocation in the hot path! The fundamental difference is that most gc-ed languages encourage you to allocate short-lived objects in the shared heap and let the garbage collector handle it, while in C you can place those objects on the stack for effectively zero-cost allocation and deallocation.
|
|
#
?
Mar 25, 2016 05:32
|
|
|
piratepilates posted:If you weren't doing viz then what would you be doing instead, and what makes you think that'll be better or less of a pain in the rear end than what you're doing right now? I still want to do dataviz but I've been focused on D3 and JS libraries. Some visualizations are not feasible with that (1000s of nodes, 60fps interactive perspective changes, etc) and would require C++, but I want to stay with JS for everything to maximize the compound-interest-learning effect.
|
|
#
?
Mar 25, 2016 06:00
|
|
|
FamDav posted:He has some valid points but you can tell his personal definition of quality is heavily informed by the stuff that he works on. His negativity towards garbage collectors and his implication that c means high quality are questionable. garbage collectors are not necessarily bad but if you can have a better system (like ARC) then you should use that C only implies high quality because many of the remaining people who still insist on using C know how to eke out some semblance of quality even then, modern C has some surprising edge cases to people who have been using it for a very long time and still (quite incorrectly) see it as a fairly straightforward translation to CPU instructions
|
|
#
?
Mar 25, 2016 06:06
|
|
|
The Destroy All Software guy dos a talk couple years back, and it was kinda jokey but I reckon there's a lot of grains of truth to it. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript At the core of it, the possibility is we will use JavaScript forever more, but will probably stop writing it directly (and arguably because most people use transpilers, this is already happening to a degree). The way we get away from the flaws of JavaScript is to write better languages, have better tooling and make it work. Arguably projects like Elm are a good step towards this, compile time validation goes a long way to avoid runtime debugging code that looks nothing like what you wrote. How long it takes to get to a point where we no longer debug JavaScript is debatable, but it'd be great if it's achievable.
|
|
#
?
Mar 25, 2016 06:10
|
|
|
Blow is making his own language now, so that's something to look forward to. I think he streams sessions about it on twitch?
|
|
#
?
Mar 25, 2016 06:34
|
|
|
Jabor posted:To be fair to garbage collection, gc delays with a continuous collector aren't really any worse or less predictable than the delays you get doing manual heap allocation. There's a reason you don't do heap allocation in the hot path! The fundamental difference is that most gc-ed languages encourage you to allocate short-lived objects in the shared heap and let the garbage collector handle it, while in C you can place those objects on the stack for effectively zero-cost allocation and deallocation. Yeah! I'm not suggesting that GC is inherently bad, it's a tradeoff with massive consequences all over your system. The usual way of dealing with allocation expense in GC languages is object pooling, which is effectively emulating memory manual allocation with the semantics you're given, by pre-allocating objects. My issue is that JS APIs tend to require short-lived heap objects to be created and destroyed, like the getImageData I described earlier. Even stuff where they should know better, you have stuff like the Web Audio requiring buffer allocation with every period. In the modern web space, you have stuff like Redux and React which are built on the ideas of immutability and pure transformations, where you return new objects instead of mutating existing ones. Languages that are pure functional tend to have optimizations for such things that turn pure transformations into mutations of existing storage, because it's easier to reason about and much cheaper. JS semantics make it difficult to do something similar, so your super clean and pure Redux is just reaming stuff directly into the GC's dead zone. I haven't seen any great discussion on the web about this. C, the language, doesn't magically fix this, but C has a culture towards being careful with allocations in your APIs, and in most cases, expecting that users pass a buffer and size.
|
|
#
?
Mar 25, 2016 06:46
|
|
|
FamDav posted:I get that game dev consumes single machine resources and requires realtime guarantees that no other branch of software dev really needs, but holy lol if you honestly say they don't output some genuinely buggy poo poo. nobody's saying game devs are perfect and bug-free, especially across the wide variety of platforms their software tends to be deployed on. i'm saying that their upbringing and culture mean that they tend to be more thoughtful about waste and performance, and less about developer productivity. they see new platforms like node.js as poor since they can't apply that same level of thoughtfulness and performance to software, even if they really wanted to. if you want to know how this poo poo affected me in production, literally a bug i investigated today, let's talk about how protobufs in python were on the average of 440kb in object size, to simply store a 16 byte-long string. we were storing next to 17000 protobufs in memory (one for each asset in a transformation pipeline), and that gave us a memory overhead of 7GB. why is protobuf so memory-hungry? nobody knows. http://stackoverflow.com/questions/6987413/google-protocol-buffers-huge-in-python
|
|
#
?
Mar 25, 2016 06:52
|
|
|
After watching the video from the handmade hero guy I watched this one: https://www.youtube.com/watch?v=o9pEzgHorH0 He talks about Google's Oauth2 Library for python and has some good examples of "coding dogma" going too far. After the NPM fiasco It made me appreciate that even big corps who pretend to know IT infrastructure and coding are not always as good as they pretend they are.
|
|
#
?
Mar 25, 2016 08:26
|
|
|
Suspicious Dish posted:Game developer and people with demoscene background tend to hate the idea of GC, because GC pauses and predictability kill you in a networked, realtime environment where the expectation is 60fps. He's right when he says C is one of the only modern, usable languages which let you effectively use system resources to their maximum potential. Instead of using new ImageElement, we use an image element pool and reuse the image elements, just because we've had so much bullshit involving Chrome not releasing (we do a lot of download image to image element in javascript, draw it in canvas) that we'd rather keep a limited number alive indefinitely. It's not even a DOM thing, there been bugs if you even just change the img src in Chrome.
|
|
#
?
Mar 25, 2016 09:26
|
|
|
Suspicious Dish posted:nobody's saying game devs are perfect and bug-free, especially across the wide variety of platforms their software tends to be deployed on. My concern is that nowhere in his definition of quality is correctness. I'm also concerned that he's approaching it from the game-centric perspective of a single release of a mostly disconnected piece of software, as compared to most other things which have ongoing maintenance/feature requests/etc. Also on tracing vs ref counting like arc, the reality is that any performant version of either will turn into a hybrid of the two concepts. http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon04Unified.pdf
|
|
#
?
Mar 25, 2016 16:19
|
|
|
can you give me a definition of "correctness" for any software project, and explain why game development doesn't meet it?
|
|
#
?
Mar 25, 2016 17:32
|
|
|
Suspicious Dish posted:can you give me a definition of "correctness" for any software project, and explain why game development doesn't meet it? I'm not saying game Dev doesn't, just that caseys quality rant never once mentioned correctness as something that's important for high quality software. Correctness in my mind is that your software conforms to the constraints you assert it does.
|
|
#
?
Mar 25, 2016 21:54
|
|
|
Analytic Engine posted:Are there serious debates on this stuff or weighing of concerns amongst architects and seniors at Goog/etc? Hahaha, no. The API implementors just shrug off real world concerns, refer to mythical future VM optimisations by other teams, then point to their toy examples running on top-spec hardware as definitive proof that Photoshop/Final Cut Pro/Ableton Live/Skype/etc are fully implementable in-browser on all platforms.  Suspicious Dish posted:Even stuff where they should know better, you have stuff like the Web Audio requiring buffer allocation with every period. Yeah, that's pretty much precisely the moment I checked out of the W3C web audio working group. It's many years later now and it's still a malformed poo poo show. ynohtna fucked around with this message at 13:54 on Apr 24, 2016 |
|
#
?
Apr 24, 2016 13:48
|
|
|
ynohtna posted:Yeah, that's pretty much precisely the moment I checked out of the W3C web audio working group. It's many years later now and it's still a malformed poo poo show.
|
|
#
?
Apr 25, 2016 05:51
|
|
|
web audio wasn't even a W3C invention though, it was a Google one. they just dumped it on the W3C in the pretense of standards. same with the Notifications API.
|
|
#
?
Apr 25, 2016 06:16
|
|
|
Google has a habit of doing that these days.
|
|
#
?
Apr 25, 2016 06:20
|
|
|
What the w3c does and doesn't accomplish is basically completely dictated by the browser manufactures -- if le Goog or Apple want to play obstructionist in whatever working group they're participating in (and they participate in most of them), then they're absolutely going to, pushing their vision and only their vision to the point where there isn't a lot that other contributors can do about it.
|
|
#
?
Apr 26, 2016 03:22
|
|
|
Lone_Strider posted:...Dworkin's Law? James Deen's >> /dev/anal law
|
|
#
?
Apr 26, 2016 03:43
|
|
|
https://medium.com/swlh/improving-angular-performance-with-1-line-of-code-a1fb814a6476#.uz30rv9m2
|
|
#
?
May 16, 2016 11:40
|
|
|
SupSuper posted:https://medium.com/swlh/improving-angular-performance-with-1-line-of-code-a1fb814a6476#.uz30rv9m2 To be fair, the docs specifically tell you to do this.
|
|
#
?
May 17, 2016 01:23
|
|
|
im not surprised that nobody reads the angular docs
|
|
#
?
May 17, 2016 06:16
|
|
|
Suspicious Dish posted:im not surprised that nobody reads 
|
|
#
?
May 17, 2016 15:48
|
|
|
Can someone post an example of not using the angular debug libraries in ToDo app form?
|
|
#
?
May 18, 2016 01:30
|
|
|
|
| # ? May 4, 2024 23:04 |
|
|
I mean, he is exactly right in the sense that these companies have huge numbers of engineers that they hire. I think what happens is that most of these engineers are grossly mismanaged, and they spend most of their days playing internet games and twiddling their thumbs. The reality is that these companies can make loads of money with very few developers, but for some reason they feel obligated to keep expanding their roster. If my college days are indicative of this situation, its that 1-2 people write 99% of the functionality. Everyone else just adds random lines of code, methods, and classes everywhere so that they can claim that they did something. WEB BUBBLE 2.0, been calling it since I was in highscool.
|
|
#
?
Jul 16, 2016 03:26
|
|