I've never owned a games console so I don't know, but I thought they could be used to play DVD films. It makes perfect sense as part of their function. ISTM anyway.
These cores are typically licensed with class/restrictions so in absolute terms yes but in the financial engineering of how the system is delivered with excess and restricted hardware no (see core types on the prior/shipping generation here https://www.ibm.com/downloads/cas/6NW3RPQV)
There are probably design reuse and RAS considerations that make it not currently worthwhile to i.e. have a distinct physical design for SAP or whatever cores.
I don't know if it's still the case, but in terms of RAS, the Z/Series CPUs from ~2004 had duplicated/compared instruction-fetch/decode and execution units.
I wouldn't be surprised as well if there was some binning that occurred – the dies are huge, so why not overprovision in the design? (Although erring on the side of slighlty more surprise in the case of some binning, since IBM mainframes seem to exist beyond the laws of commodity economics, and it looks like they're using a 5nm node.)
Yes there's a lot of cache. But rather than try to have a bunch of cores reading each cache (sharing 96MB L3 for AMD's consumer cores), now there's a lot of separate 36MB L2 caches.
(And yes, then again, some fancy protocols to create a virtual L3 cache from these L2 caches. But less cache heirarchy & more like networking. It still seems beautifully simpler in many ways to me!)
L3 caches are already basically distributed and networked through a ring bus or other NoC on many x86 chips, for example sapphire rapids has 1.875MB of L3 per core, which is pooled into a single coherent L3. Fun fact, this is smaller than each cores L2 (2MB).
From
https://chipsandcheese.com/2023/03/12/a-peek-at-sapphire-rap...
“ the chip appears to be set up to expose all four chiplets as a monolithic entity, with a single large L3 instance. Interconnect optimization gets harder when you have to connect more nodes, and SPR is a showcase of this. Intel’s mesh has to connect 56 cores with 56 L3 slices.”
There are plenty of valid ways to play D&D, and they might not all have a slow pace. But it's very easy for D&D to end up pretty slow.
In a combat scene with 4 party members and 4 enemies, 7/8 of the time it's not your turn. And if you're playing a simple character that just hits with a sword, while other players are wizards with dozens of spells to choose between their turns will naturally take longer.
Yes, this is exactly what I meant. TTRPGs typically have more time spent not doing anything compared to computer games (and board and card games too, to a lesser extent) simply by involving a group of people and being largely 'single-threaded'.
As for what I mean by narrative, much of the appeal of D&D seems to lie in crafting the story and adventure, being a part of the plot. If the setting and narrative were completely removed, and the game was reduced down to the most basic mechanical actions - go to location x,y and do foo to bar, etc., it would be a very different game.
Not to say the mechanical aspects don't make up part of the appeal of D&D and other TTRPGs too, but they're not a focus as much as in, say, a computer strategy game, or even something like an action platformer, where that is the game, and story/characters/etc. make up little (if any) of the gameplay.
You can still do things even if your character isn't. A big draw of D&D is the social aspect, you can still roleplay reacting to being hit or seeing an ally do something.
If you want to exercise your brain while waiting on your turn do like high-level chess players and think during other people's turns, I find that fun. Think how the recent decisions or rolls modify the state of the battlefield or your chances of victory.
> As for what I mean by narrative, much of the appeal of D&D seems to lie in crafting the story and adventure, being a part of the plot
That's what I was after. I know some people play in a much more involved way but when I played so many years ago I love the plot and setting, but really worked the mechanics. It may have been you got a DM or group that was just not suited to you.
But that's the problem with D&D in 2024. Role-playing games have moved far away from the constraints of old school levelling and fighting simulators. I am glad people enjoy D&D but role playing games have so much more to bring in term of narratology and experience than in ludology. It's getting drowned but it's still there. Move away from excel in disguise.
I must have played a different D&D, the group I used to play very much favored Hack & Slash. When we wanted something more narrative we used a different system (GURPS was a good one)
I prefer GURPS myself (although I prefer a "point-free" variant; you can put whatever advantages, disadvantages, skills, etc that you want to without worrying about the points or whether or not the modifier you want has been published in any book).
However, I think that GURPS can be OK for combat as well as narrative and other stuff. If you use many expansions books as well, then more options are possible. GURPS combat also has many options, and also I like the rules better than D&D in many ways. (Still, I think there are some problems with GURPS, and had tried to make up SciRPS to be better (in my opinion). Although GURPS has many skills, I think too many things are often combined in one skill; e.g. Brawling skill involves all unarmed combat (by punch, kick, claws, bite, horns, etc), but if you are skilled at only biting but not punch/kick, then it doesn't do that; skill of Morse code is the same skill as operating the communications devices to use it and are not separated; etc. "Point-free" helps a bit with this, but I think that it could be improved further, which is what I intended with SciRPS.)
To me, the RPG is that you can have many things together, including combat, magic spells, narrative, strategy/tactics, etc. This is what makes it what it is, rather than a computer game which is a different kind of game.
Although you might have plans (and the GM might have plans), many things will happen unexpectedly, due to what others are doing, due to the results of dice, etc, so that is another thing that RPG is.
That's interesting, I find the combat in GURPS to be FAR more satisfying and less restrictive than D&D. It's definitely more number crunching and more complex, but it's an internally consistent system so once you know it things flow pretty well. The leaky abstractions from D&D feel too much like it's trying to replicate a video game and doing so poorly.
Ironically it's closer to the other way around: Most video game RPGs are mechanically either based on D&D, based on another tabletop RPG that came about in the same era (Runequest, etc), or based on a tabletop RPG that was in-turn based on D&D.
Yes and no. There are some major issues in my mind like Armor Class which fortunately video games don’t really mess with. I started playing D&D back in the Skills and Powers days. You had a lot more character creation options and more granular systems than what D&D has simplified into. It’s really the latest versions of D&D that I feel like are a bad video game abstractions. Probably because of their streamlining efforts for the D20 system.
As someone whose first RPG was AD&D 2e, I get where you're coming from. IMO 3e/3.5e/PF1e didn't simplify it all that much, moreso they formalized the existing skills/powers systems that were there and added a buttload of additional classes and prestige classes for deeper customization options.
It's really 4e and 5e that simplified the game in huge ways. 5e kinda-sorta added some complexity back to it, but got rid of a lot of smaller numerical bonuses in favor of the advantage/disadvantage system.
But yeah, I definitely get where you're coming from with respect to the latest editions feeling more video-gamey. AD&D 2e and earlier had this distinctly simulationist feeling, where the intent was that you were in a world where you had to survive first and foremost and could maybe get some gold and glory if you were lucky, whereas 3e and later definitely drifted more into a "your party is/contains the main character(s) of this world" type paradigm which probably led to a lot of the more recent mechanical decisions.
It's a bit like the difference between a traditional roguelike vs a modern roguelike. One is a world simulation and you're on your own, the other is a game where you will win if you keep trying.
It's a consequence of enforcing logical consistency. You can't get around that (but if you want to suggest other behaviour and justify it, I'd be interested).
This is a frustratingly common reply to "why is this example unintuitive" across software.
Just because the problem may be higher up the chain, even up to the design of the system, doesn't mean it isn't a problem that has real consequences.
E.g. in this case, one possible solution is to not have the concept of "falsy" and "truthy", forcing 'all' to take a mapping closure (which may necessitate other changes, to the point where you now have essentially a completely different language).
It's useful to call these things out every time they trip us up, if not to fix them, then to avoid them next time somebody starts from scratch.
Okay, I'll respond because you made an interesting point, but you've also pissed me off. Let's follow this through: for a start, just because it's an intuitive doesn't mean it's wrong. However, you made me think that may be we can force at compile time that all() must take a non-empty list of Booleans where we can be sure that the problem domain should never have empty lists. I think with modern typing we can do this with dependent types (but I'm not an expert on this, but you have raised an interesting possibility, thanks).
However there are domain cases where empty lists still make sense, so you're still going to have to account for them in a rational way, and that means logically consistent, and I guarantee we will be back to what you don't like. But that's ok.
Now where you've pissed me off is this bit
> n this case, one possible solution is to not have the concept of "falsy" and "truthy"
and
> forcing 'all' to take a mapping closure
Perhaps you could un-piss me off by explaining what the bloody hell those two are supposed to mean – pretend I'm a language designer that interested in your idea (which actually I am) – what are you asking me to implement?
The poster is basically proposing something like always doing:
def all(lis: List[T], mapf: Callable [[T], bool]) -> bool:
for e in (mapf(l) for l in lis):
if e is False: return False
return True
At least that's my take on avoiding Truthy and Falsy via a mapping closure (or function?). But I don't see it solving OPs issue here when lis is empty... So maybe I'm missing something too.
Can't remember but have read you can bootstrap a forth interpreter from an amazingly low number of bytes. Maybe more of theoretical interest than practical but still.
