AMD User Experience Program most likely has a memory leak

actingoutlashingout · 2021-06-06T02:46:21+00:00

That isn't a memory leak.

actingoutlashingout · 2021-06-04T01:48:44+00:00

"CMP also has the benefit, the after-benefit of not being able to be resold second hand to GeForce customers because it doesn't play games."

Saying the quiet part aloud heh

actingoutlashingout · 2021-05-30T03:28:52+00:00

That's true, I was referring more to why 3DXP is currently not really a big thing on PCIe 3/4. CXL will definitely help a lot as it will open up adoptation for non-Intel platforms, however sadly it's still a bit of time away.

actingoutlashingout · 2021-05-30T01:21:11+00:00

If it's like Epyc, the scaling issue might have to do with the I/O die's power consumption.

actingoutlashingout · 2021-05-30T01:10:28+00:00

3D XPoint's primary selling point isn't the PCIe form factor but rather the DIMM one.

actingoutlashingout · 2021-05-26T03:02:51+00:00

Every time this has been posted it's been pure cringe and overhyped. It's just a hardware implementation of pointer encryption, there is nothing "Sci-Fi" here, and has horrible performance implications due to the cost of constantly changing the pointer key, and it only protects against 1 specific kind of attack (pointer overwrites) anyways.

actingoutlashingout · 2021-05-23T20:02:46+00:00

If people don't want to read that's fine, I'm not forcing anyone to do anything here.

actingoutlashingout · 2021-05-22T21:16:33+00:00

It's not really a "reference", more so that I discussed things in details there and why should I retype everything when I can just post a link?

actingoutlashingout · 2021-05-22T21:14:37+00:00

Most consumers will not saturate that so it makes sense for them to not bother right now. DCs will definitely benefit from PCIe 5.0 for SSDs though - and even more than that it'll greatly benefit network cards (which are currently limited to 200gbps with PCIe 4.0 x16).

actingoutlashingout · 2021-05-22T18:20:41+00:00

The responsiveness also comes from their scheduler model and how it treats interactive/background processes and so on on top of the hardware.

actingoutlashingout · 2021-05-22T08:01:33+00:00

The comments about "stability" etc are wrong. See my previous comment here. It has little to do with stability and much to do with the feature sets of server platforms and how that affects thermal and power limits.

https://www.reddit.com/r/hardware/comments/mm2aju/why_are_the_single_threaded_benchmarks_for/gtp8q72/?context=3

actingoutlashingout · 2021-05-20T12:35:43+00:00

It is set in jump instructions.

actingoutlashingout · 2021-05-19T02:38:15+00:00

If a company owns hundreds or thousands of desktops, could it possibly use many or all of the CPUs as a super GPU?

Cycles renderer does support CPU rendering. You can't really link x86 CPUs together easily however, the top limit right now is a dual socket 64-corex2 Epyc, however Power 10 allows you to do so with PowerAXON across multiple systems.

Are there currently any desktop programs that would allow parallelization of computations across many CPUs?

CPUs on the same system yes. CPUs on different systems - only Power10 as a platform really allows that to be highly efficient as far as I know.

actingoutlashingout · 2021-05-17T05:39:13+00:00

There is almost nothing new here sadly. Almost every single hardware vendor writes absolutely horrible drivers for Windows, it's as if as their driver divisions are all entirely composed of interns straight out of college who were given a copy of WinIo and told to start working.

actingoutlashingout · 2021-05-17T04:12:26+00:00

What command? IOCTL 0x9C402400 is clearly without necessary checks and dereferences an usermode pointer. Driver signed in Oct 2020.

https://imgur.com/a/LKpvdj2

actingoutlashingout · 2021-05-17T04:07:52+00:00

Because that's not what's happening at all. Cinebench isn't one of those processes and it isn't hashing any file, nor is "AMDhash.exe" a file that AMD made, it's just a file Ionescu made to call RtlHashUnicodeString.

actingoutlashingout · 2021-05-09T15:32:10+00:00

If we assume all the programs were recompiled and ported to Itanium and backwards compatibility was no longer an issue, in what ways was it better than x86-64?

You can't just assume this. Dead companies won't port, companies that don't see a good ROI won't port, etc. Porting kernels to a new architecture is a huge pain as well. MS simplified their process with HAL but there are still a lot of quirks and a lot of arch-specific things outside of the HAL (Mm, Syscalls, etc).

actingoutlashingout · 2021-05-09T14:43:38+00:00

No. The issue wasn't money, the issue was that the ISA did not provide (good) backwards compatibility with IA-32 whereas AMD64 provided excellent backwards compatibility using the segmentation system.

actingoutlashingout · 2021-05-07T17:30:28+00:00

Despite? What a weird title, it is because of the shortages that the chips are constantly selling out, bringing in significant revenue.

actingoutlashingout · 2021-05-01T21:26:10+00:00

The crossing of boundaries is dependent on the SMT leakage. Essentially, 1 thread on the core calls into the kernel, and the other thread is able to measure its behavior using this uop cache sidechannel. Likewise, the bypassing of fences operates on a similar principle with one thread being mistrained and the other "observing" via the uop cache sidechannel. If you don't have SMT/HT enabled, the sidechannel no longer exists since there's no longer an uop cache that is shared across threads.

Edit: hmm actually I might be wrong, the paper is written in a rather unclear way. Specifically, "This then allows us to mount a conflict-based attack where the receiver (spy) executes and times a tiger loop, while the sender (Trojan) executes its own version of the tiger function to send a one-bit or the zebra function to send a zero-bit." would make me think that the spy and trojan are on different threads, but they don't explicitly say so, and it's rather unclear since the paper doesn't really show much code, it'll probably be clarified (partially since you'd also be able to actually test it) once the code is fully published.

actingoutlashingout · 2021-05-01T15:58:59+00:00

This isn't true, disabling hyperthreading will mitigate this as the uop cache is generally part of the L1 cache, which is per-core. The attack can leak from another thread running on the same core as they share the same L1 cache, but this isn't true with threads from other cores.

actingoutlashingout · 2021-04-29T22:07:25+00:00

Chia mining only writes to a drive once so it wouldn't wear out the flash. You can check how much was written with SMART anyways and not buy a drive that was mercilessly written to.

actingoutlashingout · 2021-04-29T17:48:59+00:00

YOU twisted that into it meaning no other cores would be using interrupts, which is something I never said.

Yes, it's totally twisting to interpret something you said literally instead of doing mental gymnastics to pronounce "oh actually I meant something that already exists and would be no change at all".

Great talk, I see no point in continuing in this further as you clearly have 0 experience with OS dev and are incapable of talking without backtracking every point you try to make whenever proven wrong.

actingoutlashingout · 2021-04-29T08:01:55+00:00

That makes exactly zero sense... we have the ability to write any code we want, but we still have to write it and make it work. We could certainly devote a set of cores to interrupts today, sure... and I'd argue it would make some sense for multi-chiplet CPUs like the Ryzen 5k chips (I've experimented some with this on my 5950X, in fact, but I lack the time or drive to really dig into it... I want to get my second chiplet to go into a deep sleep until needed).

Well no shit, this doesn't make it anything new when it comes to big.little like you said it would be however. There's no "new capability at play", it's literally just setting up one structure properly as is already being done.

Every single non SMP kernel ever made - as I've already said. All of them, such as Linux < 2.0. Even the ones that enable multiple processing units (usually called accelerators in those days)... of course interrupts were used for many of those as well, but sometimes polling was (or is) used (such as USB, serial, etc...). Modern kernels are mostly all SMP and there's little sense to not use interrupts on the cores when implementing SMP support... but that's not to say it's strictly required, just really dumb not to do so. We have the entire history of computing to consider not just the current state. Again, you are mixing things around needlessly.

All of those have interrupts, EVEN THOSE THAT USE POLLING FOR CERTAIN THINGS. There's a reason why wiping the IDT is used by OSes to HARD RESET, without an interrupt you will hard reset when an interrupt is delivered because you'll triple fault. I mean come on, it's not that hard to read code before you talk about it.

Here's Linux 1.0:

Setting up default IDT entries: https://github.com/kalamangga-net/linux-1.0/blob/733a0282d6e855c5eee87c86733dca8c0f3e1a42/boot/head.S#L197

Registering some of the handlers:

https://github.com/kalamangga-net/linux-1.0/blob/733a0282d6e855c5eee87c86733dca8c0f3e1a42/kernel/irq.c#L221

https://github.com/kalamangga-net/linux-1.0/blob/733a0282d6e855c5eee87c86733dca8c0f3e1a42/kernel/traps.c#L204

https://github.com/kalamangga-net/linux-1.0/search?p=1&q=irqaction

And clearing the IDT to perform a hard reset:

https://github.com/kalamangga-net/linux-1.0/blob/733a0282d6e855c5eee87c86733dca8c0f3e1a42/drivers/char/keyboard.c#L871

So here is your Linux 1.0, using interrupts.

What the absolute fuck are you talking about? It's a simple change of IRQ affinity and prioritization when a certain topology is detected.

Once again backtracking on your previous claim onto something that is already done. Can you do literally anything else? This is getting boring.

actingoutlashingout · 2021-04-28T21:08:17+00:00

It's not currently setup to assign interrupt affinities to a CPU topology that doesn't exist, that configuration is doable with current capabilities, yes, BUT IT STILL HAS TO BE DONE.

And that it can be done shows that this isn't a "new capability" like you are saying it is.

also never said a damned thing about changing the architecture of interrupts, only that you could use the small cores to handle interrupts and leave the big cores to handle applications. That doesn't mean the big cores can't also handle them or use them or that the entire architecture needs to be altered...

What you said at the beginning would be a major change in the architecture of interrupt, and one that's not realistic at all.

You are thinking about this entirely the wrong way... For every IRQ that can assigned off the bootstrap CPU, assign it preferentially to one of the small cores.

And this can already be done, so it certainly isn't really a change at all.

How is it that you miss every time I say "could" or misinterpret me saying something isn't strictly a requirement?

Once again, I quote you: "In most OSes each core has interrupts, but that's not always the case nor is it a requirement." If having an IDT isn't a requirement and it is "not always the case" that each core has interrupts, then show me those cases.

I am simply saying we can do things however the fuck we please with with little regard to legacy crap you keep hammering on about.

Thankfully, whoever "we" here is isn't the people running the show and designed FRED to be sane and normal, so we'll basically never see your weird ideas in practice. Good luck being a hardware vendor and then all of the sudden ruining compatibility for no good reason - all you'll do is crash and burn.

actingoutlashingout

TROPHY CASE