More than the specific list of which RAM is compatible check the table of how many slots/GB is supported at which speed. 1x 8 GB DIMM is a lot easier to drive than 4x 48 for example. Also keep in mind a lot of it depends more on the CPU than the motherboard itself, though both play a part, and the QVL should be a "safe bet". Particularly if you're willing to throw a bit of extra voltage at the RAM.
CUDIMs should help a bit with those scaling tables due to having the clock redrivers, but we'll have to see to be certain how much.
> 1x 8 GB DIMM is a lot easier to drive than 4x 48 for example.
That's a bit of an exaggeration. What matters are DIMMs per channel, and ranks per DIMM. Consumer systems have at most two memory slots per channel, so 2x 8GB modules installed correctly is just two separate instances of one DIMM per channel, and 4x48GB is two separate instances of two DIMMs per channel, with each module being dual-rank.
The best configurations for overclocking are supposed to be motherboards with only one memory slot per channel, so that when operating with one DIMM per channel there are no empty slots providing stubs of wiring that degrade signal integrity. But very few motherboards restrict themselves like this for the sake of memory overclocking.
4x 8 GB is still a lot easier to drive at high speed than 4x 48 GB, but yes, one factor in the above comparison is indeed the number of DIMMs per channel. Ranks per DIMM is definitely a factor as well, though on large capacity DIMMs that tends to be a one sided story. Another factor in the rabbit hole is banks, tying it all back.
The other part of 2 DIMM boards is the trace lengths can be that much shorter (they need to be the same length so fewer slots means less max length to match to).
> But very few motherboards restrict themselves like this for the sake of memory overclocking.
Though I'd hope they'd finally start doing it considering the per DIMM capacities DDR5 brings (32 GB, with 64 GB planned), and most consumers really not going for capacities that'd require 2 DPC (DIMM per channel).
1 DPC should've been the default by now with the amount of 1 DPC and 2 DPC boards swapped, as it's just making things worse in the most common use case
And they’re often not stable even with the given XMP profiles. All of my XMP profiles throw errors and require backing off speed by a few hundred hertz to be stable.
Worth though. Much cheaper way to get a few extra percentage points than custom liquid cooling. And since every game where you would care about max FPS is bound by single threaded performance fast RAM is it.
Scancode vs character code is what they are describing:
Games SHOULD use scancodes for positional mappings (like WASD) and rely on the system keymap to decide what letter to display them as. There is no "probably" here, the scancode is the scancode and the keymap is the keymap.
Games OFTEN use the character codes directly regardless if it's for a positional mapping or not. This requires explicit support in the game for each possible system keymap, otherwise you end up with nonsense mappings.
The hard part about multicast is the scaling overhead of coordinating which streams should go where when it's more than "these couple things on these couple networks". Even then, the way it's a dedicated range of IPs instead of parts of public assignments pretty much shut down the idea it could ever be coordinated at scale outside of a few private networks doing it together.
It has found good success in IPTV delivery inside provider's own networks though. Cameras at casinos/hotels/Transit systems and the like too.
Ipv6 works much better with multicast. I learned about it a few years back and it's actually core to the ipv6 protocol. That means all ipv6 routers must support multicast.
There's 2^112 possible global multicast addresses with ipv6 as well (1). Though yeah, you'll still have queuing overloads as well and other issues.
I'm a big IP v6 fan but the multicast improvements are oft overstated. The meat and potatoes changes are about getting rid of broadcasts in a LAN (in a way where a dumb switch will still treat them as broadcast anyways), not about actual routing of multicast between LANs. There is no requirement IPv6 routers must support routing multicast outside of the LAN (a completely different task). There is no public assignment of ff00::/8, it's still a free for all for generic streams. There's nothing that makes routing it across LANs easier to scale and orchestrate (in fact the protocols for this are separate from IP anyways).
Effectively, the only real "improvement" for the routed multicast case is you have more private multicast addresses to pick from.
Yeah, it’s unfortunate multicast outside your own LAN isn’t more well supported. It makes sense as it’d require more orchestration above IP.
Though I’d argue that 112 bits of random addresses makes the need for global registration largely unnecessary. Similarly to the rest of IPv6, the address is intentionally so large that it allows random IP generation with very low collision probability.
Pushing packets in software is generally brutal but multicast/broadcast should be inherently easier. It's less "copy this packet 27 times" and more "instead of receiving 27 packets and sending 27 packets you receive 1 packet and send it 27 times before you remove it from memory". The "hard" part becomes dealing with the queues filling up because you're inherently able to churn out so much more data than you're able to receive vs unicast.
You'll still run into trouble with anything wanting to allow everything but trying to do NAT. I'd hazard to guess this actually still uses UDP under the covers for that reason (but haven't bothered to verify). QUIC and HTTP/3 went that route for the same reason.
The lack of support for the built in microphone is a bit of a catch you don't see mentioned too often. It feels like one of those things that would have come early on and it's not necessarily the first thing you're going to reach for but it can be a bit surprising when you find out it's just not there.
None of those orgs is going to run leaner if AI is a bust. They'll invest as much, if not more, into trying to find other ways to grow - exactly the same reason they all invested in AI in the first place.
> They'll invest as much, if not more, into trying to find other ways to grow
Management will try to hold on to the capital for as long as shareholders let them. But if the growth prospects from AI significantly diminish, 20,000 jobs in tech is a pretty conservative estimate for lay-offs.
It runs pretty much as described - you enter `=py` and it becomes a place to dump python code directly without configuring anything. The "catch" is it runs in the cloud and you need to buy the appropriate license level.
CUDIMs should help a bit with those scaling tables due to having the clock redrivers, but we'll have to see to be certain how much.
reply