Playstation Architecture: A Practical Analysis • Hacker News Board

Re: Playstation Architecture: A Practical Analysis

#71

Post by softfalcon » Tue, Apr 21, 2020, 2:24 PM UTC

Koshkin wrote: post #63

ddoolin wrote: post #2

It's crazy to see just how far they've come from the first console to the latest and all the lessons they've learned along the way. https://www.youtube.com/watch?v=ph8LyNIT9sg (Some Playstation 5 architecture highlights).

Well, as much as I would love to share the excitement, all they've come to is what essentially amounts to another gaming PC. Not sure how 'far' this is, but clearly all innovation happens now on the PC side. (It almost seems now that the fact that the earlier Playstation models and other consoles had the custom architecture that was different from PC may have had to do with the need to provide enough power in a small…

Custom architecture was prevalent back then because there weren't any real standards for developing a system that could render 3D graphics. If you wanted 3D rendering, you had to do it yourself. No one was selling you a pre-built stable chip.

The now defunct fixed function pipeline was still being formalized in PCs, let alone consoles. Each console was a massive exploration into what could be done and who could make the best SDK for that hardware to entice developers to make games.

The fact that all modern consoles and PC's are similar should be applauded. It's the culmination of decades of hardware and software learnings, standardized into the optimal hardware for graphics and game performance.

The fact that they all found what they needed in a similar architecture footprint is good for hardware design, good for developers, good for business, good for porting, good for optimization, and finally, good for performance.

Sony, Nintendo, and Microsoft are no longer able to design the latest and greatest chipsets. The complexity is just too much for them to reasonably pay to do so. That's why AMD does it for them. Why would you reinvent the wheel when someone has already spent decades making Ferrari's and is begging you to use their engine at a discount, bulk manufacturing included?

Back during the PS1, Sony had a heavy hand in the graphics card design. Not as much anymore. They tell AMD what they want to do and AMD eschews an existing chip to do it for them.

I know it sounds less glamorous, but honestly, it's the most remarkable thing I've ever seen in the history of modern manufacturing, short of landing on the moon. Having one company able to provide chipsets for any and all applications, including gaming at a practical whim seems pretty amazing.

tldr; The consoles are all the same because AMD/nVidia are so much better at hardware design than Microsoft/Sony/Nintendo that it's not even funny anymore. If someone has the latest and greatest already available for licensing, just buy it and get on with making amazing games.

Re: Playstation Architecture: A Practical Analysis

#72

Post by clownpenis_fart » Tue, Apr 21, 2020, 2:26 PM UTC

papito wrote: post #36

pjmlp wrote: post #23

Earlier quoted context omitted.

Like shipping Electron apps.

Writing Electron apps for me, as a matter of fact, brings back the time when one had to be hyper-mindful of CPU cycles, just like back in the day when I was writing Windows apps in C++. Everything is going through the prism of "but how much will it cost in terms of performance? Granted, this should be the case for server software as well, but in case of clients, you don't know what ghetto shit your code will run on -…

Here it is. The stupidest thing I've read all day.

Re: Playstation Architecture: A Practical Analysis

#73

Post by commandlinefan » Tue, Apr 21, 2020, 2:27 PM UTC

kdmccormick wrote: post #56

fxtentacle wrote: post #46

It makes me feel nostalgic to read about the times when people still tried to understand the hardware and make things work amazingly well despite harsh resource limits. Nowadays, even simplistic programs take ages on a device 1000 times more powerful. I had time to read this article because restarting our ruby development server is so excruciatingly slow. It seems the craftsmanship aspect of computer programming is g…

A Ruby dev server doesn't need to be slow. Put some "craftsmanship" resources into making your dev tools tighter and your app less bloated with dependencies and startup steps.

> Put some "craftsmanship" resources

Hard to find time for when you have 30 JIRA tickets every two-week "sprint", none of which have anything to do with improving performance.

Re: Playstation Architecture: A Practical Analysis

#74

Post by thomasfortes » Tue, Apr 21, 2020, 2:28 PM UTC

junke wrote: post #28

glandium wrote: post #6

Earlier quoted context omitted.

Extended version: https://www.youtube.com/watch?v=pSHj5UKSylk

Andy Gavin (in the video) was also responsible for the development of GOAL, Game Oriented Assembly Lisp ( https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp )

Naughty dog (the studio founded by Gavin and Jason Rubin) is also home of the ICE team, a technology hub for Sony titles, I wonder if Sony saw the tech expertise culture in the studio and decided to put a team to handle psx dev tech with them.

https://en.m.wikipedia.org/wiki/Naughty_Dog#ICE_Team

Re: Playstation Architecture: A Practical Analysis

#75

Post by asveikau » Tue, Apr 21, 2020, 2:28 PM UTC

pixelrevision wrote: post #61

jstimpfle wrote: post #38

Earlier quoted context omitted.

> Which is why I find so ironic that many still think only languages like Assembly, C or C++ have a place in IoT on devices like ESP32. Short answer, Parkinson's law. When I browse the Web, open my Windows File Explorer, open Photoshop, open Visual Studio, open just a graphical application that needs GPU acceleration, or do whatever thing that should not be an issue, I find that Parkinson's law very much applies. htt…

Legacy products like visual studio and photoshop also suffer from age. Those codebases are both over 20 years old and have a gazillion features that customers start to rely on. Add in that and codebase that old will be slower to make changes on then something fresh and you end up where they are.

Visual studio had a UI rewrite to .net about a decade ago.

VSCode is electron.

If they had kept maintaining the old thing maybe they would experience less performance issues, which you say is suffering from age, but actually they threw out the old thing and rewrote on costlier and more recent frameworks.

Re: Playstation Architecture: A Practical Analysis

#76

Post by hvs » Tue, Apr 21, 2020, 2:32 PM UTC

fxtentacle wrote: post #46

It makes me feel nostalgic to read about the times when people still tried to understand the hardware and make things work amazingly well despite harsh resource limits. Nowadays, even simplistic programs take ages on a device 1000 times more powerful. I had time to read this article because restarting our ruby development server is so excruciatingly slow. It seems the craftsmanship aspect of computer programming is g…

I was a programmer back then, and it's not the "golden age of programming" that some make it out to be. For one thing, WE were complaining about how big and bloated software was becoming compared to the "old days" when programmers only had 64KB to work with. On top of that, it took SO LONG to develop basic functionality that you could probably build in a one hour language tutorial now. Things that were excruciating to build are trivial now. Yes, there is a cost. Abstraction adds bloat, but it also allows developers to be much more productive.

I have a friend I play go with that is an old Univac programmer (he's 30 years older than me) and he often pulls the "call me when you have to use punch cards".

Developers always look back on the past a bit wistfully, but I assure you that some things never change.

Re: Playstation Architecture: A Practical Analysis

#77

Post by commandlinefan » Tue, Apr 21, 2020, 2:37 PM UTC

pjmlp wrote: post #24

mikorym wrote: post #16

Earlier quoted context omitted.

I think these programmers were forced to understand their subject matter much better than today. Say for (a silly) example you want the first 10 000 digits of Pi. It's pretty easy to just store that today. But back then you didn't just have to know what Pi is , you had to have the smallest program to calculate it that you can think of. Would be interesting to hear too how Tekken 3's coders managed to work with 2 MB o…

Which is why I find so ironic that many still think only languages like Assembly, C or C++ have a place in IoT on devices like ESP32. Sure, we used Assembly when performance was the ultimate goal, but also plenty of high level languages, including stuff like Clipper for database front ends. 512 KB with a couple of MHz are already capable of doing a lot of stuff, one just needs to actually think how to properly implem…

> think how to properly implement it

OTOH, the only people who can think how to properly implement it are people who are also perfectly comfortable with Assembly, C or C++.

Re: Playstation Architecture: A Practical Analysis

#78

Post by commandlinefan » Tue, Apr 21, 2020, 2:41 PM UTC

jstimpfle wrote: post #52

pjc50 wrote: post #49

Earlier quoted context omitted.

Java (the language) is not especially slow; back in the mid 2000s I was optimising a Java GUI to display hundreds of thousands of nodes for chip design clock trees. Java (the culture) makes it hard to be performant. There's a great tendency to use all sorts of frameworks and elaborate object systems where much simpler code would give you at least 90% of the functionality for 10x the performance. But if you get some p…

Yep I agree. Java isn't slow if you build a trivial application. Or an HTTP server. Or something for batch processing. Or if you're a masochist working around performance issues until you reach about ~C level of performance and performance "robustness". The problem is what Java encourages you to do. And I didn't want to single out a language; Java is just one that I revisit from time to time and I'm always astonished…

> tendency for C programs to be faster

I was involved in a massive rewrite of a website from C to Java a while back. One coworker observed that, when they were coding in C, it took a lot longer to get anything working, but once you did, it was pretty solid: C had a tendency to just crash if anything was wrong, so you'd work for quite a while before you got something that didn't crash consistently. Java, on the other hand, allowed you to get something working (that is, running without crashing) much quicker: but the things that were out of place were still there, they just caused harder-to-find problems that were much more likely to become customer-facing before they were caught.

Re: Playstation Architecture: A Practical Analysis

#79

Post by as1mov » Tue, Apr 21, 2020, 2:42 PM UTC

fxtentacle wrote: post #46

It makes me feel nostalgic to read about the times when people still tried to understand the hardware and make things work amazingly well despite harsh resource limits. Nowadays, even simplistic programs take ages on a device 1000 times more powerful. I had time to read this article because restarting our ruby development server is so excruciatingly slow. It seems the craftsmanship aspect of computer programming is g…

I've found this sentiment common in posts like these, but most of them seem to conveniently ignore how complex software (especially video games) and hardware has become. Compare the screenshots of a game released in the PS1 era, to even a low budget indie title released today (eg. Hellblade), that's just the graphics, you have other aspects like multiplayer and AI. Games aren't written from scratch on bare metal machines now because it's not feasible to do so.

This applies to general software too, things that weren't big deal/non-existent in 90's are important now, security, networking, OS native UI frameworks. The OS itself doesn't give you FFA access to the machine anyway.

Also if you really wanted, instead of using Ruby you could bang out a backend/REST API using assembly[1]/C[2] even today, just that nobody wants to do that because it's a fucking pain in the ass.

[1] https://asm32.info/index.cgi?page=content/0_MiniMagAsm/index...

[2] https://kore.io/

Re: Playstation Architecture: A Practical Analysis

#80

Post by inform880 » Tue, Apr 21, 2020, 2:48 PM UTC

AnIdiotOnTheNet wrote: post #60

inform880 wrote: post #55

Earlier quoted context omitted.

I understand that Electron apps tend to be a resource hog, but what other options for software create as many cross platform opportunities with as much work? I think for every single greedy developer/company there's another small software project only able to get off the ground because of the maximized opportunities. This is coming from a relatively new full time developer who's trying to get a small side project off…

> I understand that Electron apps tend to be a resource hog, but what other options for software create as many cross platform opportunities with as much work? Is laziness a good excuse for poor software? For wasting the time and resources of every one who uses the application? For disregarding the conventions of the host platform including any user preferences and accessibility features?

> For wasting the time and resources of every one who uses the application?

I don't believe this argument for a second, with the ubiquitousness of successful Electron apps.