Announcement

Collapse
No announcement yet.

The Performance Impact Of MDS / Zombieload Plus The Overall Cost Now Of Spectre/Meltdown/L1TF/MDS

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • hotaru
    replied
    Originally posted by Michael View Post

    I've looked at it, power consumption is the same with/without the mitigations.
    the same for an entire task, or the same per unit of time? if it's per unit of time and a task takes 10% longer, the overal power consumption is higher.

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by xfcemint View Post

    Peak MIPS is a bad way to measure performance.

    Realistically, a 486-DX4 100 MHz is about 100x slower than a modern single-core. I did some research on this. And for multi-core, it doesn't make much sense to compare, like apples to oranges.
    Are you perhaps trashing the cache? I wonder because 100x is roughly the difference I see in my lock-less queue between a modern Xeon Platinum and a ARM A-53 (Rpi3B+) and the ARM is itself orders of magnitude faster than a 486.

    Leave a comment:


  • Michael
    replied
    Originally posted by hydrian View Post
    Has anyone considered the power draw/battery performance with and without mitigations? While performance is going down, is it making the CPU more or less efficient?
    Also, what about thermals? Do the mitigation make a CPU run hotter, cooler, or is there no real difference?

    Both of the above factors are big factors in laptops/ultrabooks and other SFF machines.
    I've looked at it, power consumption is the same with/without the mitigations.

    Leave a comment:


  • hydrian
    replied
    Has anyone considered the power draw/battery performance with and without mitigations? While performance is going down, is it making the CPU more or less efficient?
    Also, what about thermals? Do the mitigation make a CPU run hotter, cooler, or is there no real difference?

    Both of the above factors are big factors in laptops/ultrabooks and other SFF machines.

    Leave a comment:


  • Charlie68
    replied
    openSUSE Tumbleweed

    Leave a comment:


  • GreenReaper
    replied
    While software video rendering is CPU-intensive, it doesn't strike me as a task involving the kernel, unless data needs to be transferred to or from disk (which can usually be done in large chunks for video) or certain kinds of synchronization or memory allocation takes place.

    It's the cost of switching from user to kernel contexts and back again, and the protective methods designed to prevent against leaks of data throughout this process, which have caused the greatest impact. Those applications which must perform such activities tend to be the most-impacted.

    If you were running a task which did make such calls on threads running on the same cores as threads doing video rendering, it might also have a significant impact (potentially running worse than the 'no hyperthreading' case, as at least then it would run uninterrupted for longer periods of time, and have full use of the caches).

    Leave a comment:


  • tildearrow
    replied
    dav1d results for overall mitigation impact:

    Summer Nature 4K

    -No Mitigations-

    6800K: 88.65fps
    8700K: 111.61fps
    7980XE: 151.70fps
    2700X: 105.69fps
    2990WX: 176.61fps

    -Mitigations-

    6800K: 88.26fps
    8700K: 111.13fps
    7980XE: 151.70fps
    2700X: 105.90fps (!)
    2990WX: 174.05fps

    -Mitigations plus No Hyper-Threading-

    6800K: 66.75fps
    8700K: 88.13fps
    7980XE: 139.65fps
    2700X: N/A
    2990WX: N/A

    Summer Nature 1080p

    -No Mitigations-

    6800K: 279.95fps
    8700K: 377.27fps
    7980XE: 287.77fps
    2700X: 306.11fps
    2990WX: 457.81fps

    -Mitigations-

    6800K: 279.08fps
    8700K: 375.31fps
    7980XE: 288fps (!)
    2700X: 307.94fps (!)
    2990WX: 456.07fps

    -Mitigations plus No Hyper-Threading-

    6800K: 226.46fps
    8700K: 300.25fps
    7980XE: 237.82fps
    2700X: N/A
    2990WX: N/A

    I thought by v0.2 I'd see this thing in FPS rather than vague seconds?

    Leave a comment:


  • tildearrow
    replied
    dav1d results:

    -MDS Mitigated-

    E3-1275v6: 74.97fps
    8700K: 111.14fps
    7980XE: 151.26fps
    9900K: 135.35fps

    -MDS Vulnerable-

    E3-1275v6: 75.09fps
    8700K: 111.69fps
    7980XE: 151.71fps
    9900K: 135.55fps

    I have to keep doing this until my patches are merged...

    Leave a comment:


  • audir8
    replied
    Originally posted by Cybmax View Post

    How come it is "ok" to loose performance due to security patches that fix some hypothetical scenario in the computing world... and even being called somewhat of a dumbass for pointing that out... While VW owners loosing power and torque after the "dieselgate fix" is applied have a perfectly valid reason to demand their money back?

    I mean, in the world of IT almost anything is acceptable, while when it comes to most other stuff in the world you would never ever get away with something like that. How would it look if you got to your VW dealer and complains about loosing power, and the response was "Oh we are sorry we messed that up, but you could always buy the new 2019 model!"? This is something that seems totally oki when it comes to computers...
    VW owners got fixes and money back because of the decrease in MPG and power (with an emissions fix), and buyouts because of the harm to the environment. Less MPG does mean you'll be spending more. Less power doesn't necessarily mean you'll get somewhere slower when obeying speed limits. Also, the environment is more important than the performance of a still correctly functioning processor.

    Originally posted by xfcemint View Post
    ...Why can't they replace my CPU with a propery working model?...
    I mostly don't think Intel knew what it was doing. These flaws are hard to exploit, because there are no direct ways to attack buffers in any of the exploits, it's all indirect and still pretty hard to do. If any of these attacks were more direct, you might have a case like the divide by zero bug where Intel did recall the processors. Without evidence though, you'll never prove either way, and it's plausible to think the choice of more performance was correct if it wasn't provable that indirect exploits could be done... like in the case of Spectre.

    For the length of time this has been out there though, this fuck up does somewhat go in the Facebook category of "moved too fast, and fucked things up." So as a consumer, I'm mostly hoping the tech companies make sure they aren't releasing stuff that will have bad unknown collateral consequences later on. Though compared to the still on-going Facebook fuck ups, Intel's is still relatively minor. We all still have working processors with working software. Performance is still relative to your setup, more/faster RAM/SSD/GPU are still far more likely to help you get more performance on any variety of real world tasks than switching from a 7700k (buggy) to a newer 9700k (fixed).
    Last edited by audir8; 19 May 2019, 06:21 PM.

    Leave a comment:


  • Mario Junior
    replied
    Originally posted by Code Artisan View Post
    https://make-linux-fast-again.com/

    Code:
    noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off[URL="https://make-linux-fast-again.com/"][/URL]
    Just use mitigations=off

    Leave a comment:

Working...
X