Earlier quoted context omitted.
I am looking forward to seeing this post in 2034!
tbh, i personally think the article is timeless and beautiful
Oh it wasn't a criticism, it's a lovely article.
Black Triangles (2014)
41–50 of 79 posts
Re: Black Triangles (2014)
#42Earlier quoted context omitted.
Have you written a serious game engine? Parent is right, a bunch of them basically are a real-time OS sitting on a small amount of the underlying OS ( if one exists). When you have to write your own malloc() and fopen(), and your own thread scheduling, that counts as Operating System. This is becoming less true today, as the hardware gets better and bigger and faster and resources are less constrained, but it wasn’t…
> Parent is right, a bunch of them basically are a real-time OS sitting on a small amount of the underlying OS (if one exists). When you have to write your own malloc() and fopen(), and your own thread scheduling, I don't doubt that game developers do this, but I've never really heard a satisfying reason why, besides vague hand-waving about "needing more performance". I'm not a game developer though, so maybe it's tr…
I'm not a game developer, but I was similarly lead to believe that stl containers were especially slow compared to other implementations. This is supposed to be because the stl has more restrictions on the implementation owing to the interface they have to export. The stl hash table for example has to provide low level access to the buckets, even though modern hash tables usually avoid having buckets in the first place. By lifting these restrictions the performance can be improved tremendously. Facebook, for example, are supposed to have their own in house hash table implementation to achieve this.
Re: Black Triangles (2014)
#43One thing that’s interesting today is how in the corporate world, even in big tech companies where one might naively think black triangles with explanations might be appreciated by more technically literate managers, working on these sorts of building blocks for big wins will often actually result in projects and teams getting axed. I’ve seen serious attempts at innovation get thrown out the window a number of times…
working on these sorts of building blocks for big
wins will often actually result in projects and teams
getting axed.
My manager (a software engineer himself, still involved in day-to-day engineering on this product) said that it couldn't be meaningfully bettered. But in the meantime, we were taking a beating from our primary customer upon whom we depended for ~75% of our revenue. I viewed this existing solution as a potential company-killer.
So I spent some nights and weekends hacking together an alternative. Got the run time down from several hours to thirty seconds using some basic caching and a basic tree structure... not exactly advanced black magic. It also required about 50% less code.
I excitedly showed it to my manager. I walked him through the code. He became angry for the following "reasons."
1. Instead of making the code smaller, he felt it made the code larger. This is because he failed to comprehend that my MVP "hey this is possible" prototype didn't actually remove the old solution. It was just an MVP! I explained this to him but apparently it didn't take.
2. He couldn't understand the underlying concept. Again, it was... a tree. Something you would encounter in a 200-level computer science course, at the very latest.
3. My code lacked tests. Again... this was a "nights and weekends" MVP.
Probably the single fucking stupidest moment in the history of my career. I am not a person who typically has communication issues with managers or coworkers. I was dumbfounded that he was dumbfounded and to this day I am absolutely baffled by this whole incident. Our relationship had been deteriorating somewhat but not to the extent that would explain his brain-dead and hostile response.
Unsurprisingly this lead to my departure from the company.
Re: Black Triangles (2014)
#44I refer to it as getting an ant tunnel through the mountain
Re: Black Triangles (2014)
#45Earlier quoted context omitted.
Have you written a serious game engine? Parent is right, a bunch of them basically are a real-time OS sitting on a small amount of the underlying OS ( if one exists). When you have to write your own malloc() and fopen(), and your own thread scheduling, that counts as Operating System. This is becoming less true today, as the hardware gets better and bigger and faster and resources are less constrained, but it wasn’t…
> Parent is right, a bunch of them basically are a real-time OS sitting on a small amount of the underlying OS (if one exists). When you have to write your own malloc() and fopen(), and your own thread scheduling, I don't doubt that game developers do this, but I've never really heard a satisfying reason why, besides vague hand-waving about "needing more performance". I'm not a game developer though, so maybe it's tr…
Custom allocators were needed, and often still are, in order to have enough memory in the first place (for example memory pools for specific sized small allocations are common), to avoid fragmentation that could lead to out-of-memory conditions or the need to defrag over time, to have control over how the free list regains memory and how long it takes. It’s important in a real-time or embedded application to prioritize predictability over some of the host OS’s goals, and to have stronger guarantees.
IIRC I think one of the primary reasons the EASTL was developed is because the STL at the time did not allow overriding the default built-in memory allocator, and because STL did a bunch of memory allocation.
This is changing and games use lots more STL and dynamic memory allocation than they used to, but a decade ago and earlier, STL use was generally discouraged for the same reason that any and all heap allocations were discouraged for gameplay and engine code: because doing heap allocations during real-time and in performance critical sections can impact performance significantly, and can be dangerous. This is still very true today: the first rule of high performance is to avoid dynamic memory allocations in the inner loop -- true in JavaScript, CUDA, C++, even Python. Dynamic memory allocations can sneak up on you too. It might seem small or innocuous until it piles up or pushes you over a threshold or hits some kind of lock condition.
One mentality I learned game programming that can be counter-intuitive at first is how and when to reserve the maximum amount of memory you need for a given feature and never change it. It can feel at first like you’re hogging way too much, or that something’s wrong with coding that way, but it’s much more predictable, can be much higher performance, and it can be safer for the overall system to ensure that you will never have a weird condition where several things all need more memory than expected at the same time and it suddenly crashes.
Re: Black Triangles (2014)
#46A long, long time ago:
Me: Look at this dot!
Mom: You put a dot on the screen?
Me: Yes! Now hit the keys! You can move it!
Re: Black Triangles (2014)
#47One thing that’s interesting today is how in the corporate world, even in big tech companies where one might naively think black triangles with explanations might be appreciated by more technically literate managers, working on these sorts of building blocks for big wins will often actually result in projects and teams getting axed. I’ve seen serious attempts at innovation get thrown out the window a number of times…
This is the most important bit, to me:
> By the end of the day, we had complete models on the screen, manipulating them with the controllers. Within a week, we had an environment to move the model through.
The Black Triangle was a leading indicator of a payoff that began happening by the end of the day. Too many similar projects result in a constant string of promises that we are just about to turn the corner on velocity/capability if only we would let the engineers focus on this refactor for a bit longer.
In practice, "Black Triangles" projects are bets like any other. If they work out, they unlock faster velocity and the ability to deliver better features. Often they deliver nothing but a refactor to someone's idea of a better architecture, and are lucky to ever reach breakeven on engineering time.
Re: Black Triangles (2014)
#48One thing that’s interesting today is how in the corporate world, even in big tech companies where one might naively think black triangles with explanations might be appreciated by more technically literate managers, working on these sorts of building blocks for big wins will often actually result in projects and teams getting axed. I’ve seen serious attempts at innovation get thrown out the window a number of times…
In my experience, maybe half of "foundation" or "infrastructure" work is actually bullshit. That's probably why it's not a carte blanche to just do whatever with nothing to show for it until "later".
Re: Black Triangles (2014)
#49Earlier quoted context omitted.
Have you written a serious game engine? Parent is right, a bunch of them basically are a real-time OS sitting on a small amount of the underlying OS ( if one exists). When you have to write your own malloc() and fopen(), and your own thread scheduling, that counts as Operating System. This is becoming less true today, as the hardware gets better and bigger and faster and resources are less constrained, but it wasn’t…
> Parent is right, a bunch of them basically are a real-time OS sitting on a small amount of the underlying OS (if one exists). When you have to write your own malloc() and fopen(), and your own thread scheduling, I don't doubt that game developers do this, but I've never really heard a satisfying reason why, besides vague hand-waving about "needing more performance". I'm not a game developer though, so maybe it's tr…
That’s a great example to raise, and I think you’re right to point it out.
Any field is susceptible to cargo-culting, especially ppl who are just trying to get their job done so they focus on having to rediscover everything their leaders are claiming to have verified.
But for the specific claim you’re challenging, it’s hard to really convey the realities without having some experience in those problems.
High level it really comes down to:
1. Relaxing some generic constraints to apply game specific ones
2. Fine grained control over execution, again by relaxing some constraints
3. Game programming can play fast and loose with a lot of things for the sake of speed; this is not generalizable
Re: Black Triangles (2014)
#50[flagged]
[deleted]