Intel making us slow down
-
@boomzilla said in Intel making us slow down:
@gąska said in Intel making us slow down:
@boomzilla except the Unix Philosophy™ is to have make fire up a completely separate, completely isolated, cold-started instance of gcc for every .cpp file you have. I'm pretty sure it's the only working mode gcc and clang have, so changing build system can't help here. Visual C++ might be better in this regard, though I'm rather skeptical. The best you can do is precompiled header, but it can only get you so far.
So what? The OS still caches files for you. I dunno, I guess that'd still be hit by the slowdown.
The OS caches are still behind syscall.
Edit: damn those ninjas.
-
@weng said in Intel making us slow down:
Sigh. I guess I'll start evaluating architectural changes to reduce the number of syscalls....
Don't forget that TLB misses are syscalls too.
-
@masonwheeler said in Intel making us slow down:
@weng said in Intel making us slow down:
@lolwhat Nah, I'll roll with incompetence as the root cause here.
I'll be switching back to AMD at home for the foreseeable future.
Does this even affect home systems? (ie. do you and I have any real reason to be concerned about our home PCs?) From what I've read, it appears that this is an issue that's mostly a headache for cloud servers and other shared systems.)
If you patch, you get the speed hit. If you don't patch, you're vulnerable, and you almost certainly do run untrustworthy code (think javascript) in sandboxes.
-
@pleegwat said in Intel making us slow down:
If you don't patch, you're vulnerable, and you almost certainly do run untrustworthy code (think javascript) in sandboxes.
I think we'll have to wait until the embargo lifts to really see what the magnitude of risk is, though. Taking advantage of speculative execution for a privileged read (especially doing so from a sandbox) seems like a really sophisticated attack to which most users aren't going to be subjected. There are plenty of less-sophisticated attacks that will work as well or better.
High-profile targets (e.g. financial institutions, government agencies, military activities) obviously have to patch right away.
-
@heterodox said in Intel making us slow down:
I think we'll have to wait until
the embargo liftsthey finally figure out the right catchy backronym and set up a glitzy website to overhype the vulnerabilityFTF2018.
-
@heterodox said in Intel making us slow down:
aking advantage of speculative execution for a privileged read (especially doing so from a sandbox) seems like a really sophisticated attack to which most users aren't going to be subjected. There are plenty of less-sophisticated attacks that will work as well or better.
True, but once someone figures it out the technique will be out there and you don't have to know how to build a tool to use it.
-
@heterodox Except in Windowsland, we now have unified patches.
You either get all the patches or none ever again.
-
@izzion said in Intel making us slow down:
@heterodox said in Intel making us slow down:
I think we'll have to wait until
the embargo liftsthey finally figure out the right catchy backronym and set up a glitzy website to overhype the vulnerabilityFTF2018.
The proposed FUCKWIT name from the Linux guys is good enough.
-
@weng said in Intel making us slow down:
@heterodox Except in Windowsland, we now have unified patches.
You either get all the patches or none ever again.
You can still selectively ignore particular updates.
...for now.
-
@gąska Not if you intend to apply the future ones (so I am assured by WtfCorp IT)
-
@weng weird. I ignored Fail Craters Pupdate some time ago and still receive others:
-
And so it begins:
*checks*
Heh. Those puts are up 73% already.
-
@gąska said in Intel making us slow down:
have make fire up a completely separate, completely isolated, cold-started instance of gcc for every .cpp file you have. I'm pretty sure it's the only working mode gcc and clang have, so changing build system can't help here.
Yeah that philosophy is optimized for when you make a change in one or two files and then rebuild - only the files you changed need to be rebuilt. If you wanted to, you could pass all source files to the compiler every time, but that means a single change requires recompiling everything. For small projects that's usually much more efficient than compiling each file separately.
-
@lb_ said in Intel making us slow down:
@gąska said in Intel making us slow down:
have make fire up a completely separate, completely isolated, cold-started instance of gcc for every .cpp file you have. I'm pretty sure it's the only working mode gcc and clang have, so changing build system can't help here.
Yeah that philosophy is optimized for when you make a change in one or two files and then rebuild - only the files you changed need to be rebuilt. If you wanted to, you could pass all source files to the compiler every time, but that means a single change requires recompiling everything. For small projects that's usually much more efficient than compiling each file separately.
Make a change in one header and suddenly all your files get rebuilt.
-
@ben_lubar said in Intel making us slow down:
Make a change in one header and suddenly all your files get rebuilt.
Hit backspace and they all get rebuilt twice.
Filed Under: FUCKING HELL
-
@masonwheeler said in Intel making us slow down:
And so it begins:
*checks*
Heh. Those puts are up 73% already.
...and it's starting to recover on news of Intel downplaying the vulnerability and saying it's not nearly as big a deal as everyone thinks it is. This may or may not be true, but the market's acting on it. Just closed it out for a very nice one-day profit of over 30%. :D
I don't do that very often (I think the last time was 2 years ago) but it's a lot of fun when the right opportunity comes along.
-
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
Intel believes these exploits do not have the potential to corrupt, modify or delete data.
ORLY?
-
@ben_lubar said in Intel making us slow down:
Make a change in one header and suddenly all your files get rebuilt.
As opposed to Java where it all just silently compiles and then you get runtime errors about non-existent methods.
-
@lb_ said in Intel making us slow down:
As opposed to Java where it all just silently compiles and then you get runtime errors about non-existent methods.
What are you using to build your program?
-
@lolwhat said in Intel making us slow down:
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
Intel believes these exploits do not have the potential to corrupt, modify or delete data.
ORLY?
That's reading data inappropriately. I don't see any sign of data being modified or deleted there.
-
@unperverted-vixen said in Intel making us slow down:
That's reading data inappropriately. I don't see any sign of data being modified or deleted there.
I think Intel's being a little bit disingenuous here. This exploit can't be used to modify or delete data, but (according to an article posted yesterday at least) it can reveal information that an attacker would need in order to target a Rowhammer attack against the OS, which can modify data, but only works if you know specifically what data to modify. The fear is of these two attacks being combined.
-
@boomzilla I ran into this with maven and the Oracle JDK
-
@bb36e Oh, I use
ant
.
-
Question--if it's the syscalls that will be slowed down (by 20-30%?), what percentage of the total time is spent in syscalls for an average (non-compiling) user? There's a big difference in taking 1.2x as long on 0.000001% of the workload (negligible overall) and taking 1.2x as long in 90% of the workload.
Are there workloads that depend heavily on syscalls? Small constant file access, but what types of normal uses do lots of those? This is an area I know really nothing about.
-
I know TortoiseGIT got slow AF after 1709 update, wonder if it was related, or if it's just going to get worse after patch Tues.
-
@masonwheeler said in Intel making us slow down:
@unperverted-vixen said in Intel making us slow down:
That's reading data inappropriately. I don't see any sign of data being modified or deleted there.
I think Intel's being a little bit disingenuous here. This exploit can't be used to modify or delete data, but (according to an article posted yesterday at least) it can reveal information that an attacker would need in order to target a Rowhammer attack against the OS, which can modify data, but only works if you know specifically what data to modify. The fear is of these two attacks being combined.
Inglourious Basterds - Hans Landa: "Bingo!" – 00:22
— NPBeatz
-
@dangeruss said in Intel making us slow down:
I know TortoiseGIT got slow AF after 1709 update, wonder if it was related, or if it's just going to get worse after patch Tues.
TortoiseGIT also snuck into your carport last night and quietly let 5 lbs out of all the tires on your van.
-
@blakeyrat said in Intel making us slow down:
5 lbs
Unless tortoisevn shaved off 5lb of rubber, I think you meant to say 5lb/in²
-
@bb36e you do realize that's no different from a DLL missing at runtime, right?
-
@bb36e I'm sure he meant 5 load-bearing steelbelts. Expect a sidewall blowout soon.
-
@benjamin-hall said in Intel making us slow down:
Question--if it's the syscalls that will be slowed down (by 20-30%?), what percentage of the total time is spent in syscalls for an average (non-compiling) user?
AFAIK, the 20-30% that people throw around were for some random benchmark, and not the syscalls themselves. The benchmarks are all over the place anyway. Somebody made a program that repeatedly does the syscall for to get the processes' PID, and that was like maybe 3x slower (with a non-final version of the patches, I think). So that would probably maybe be close to the worst case? Other benchmarks are apparently barely affected (like, pure number crunching).
There's this tweet with a fairly suspicious benchmark: 50% slowdown on
du -s
(i.e.,figuring out the size of a folder's contents).So essentially ...
-
@lb_ said in Intel making us slow down:
@gąska said in Intel making us slow down:
have make fire up a completely separate, completely isolated, cold-started instance of gcc for every .cpp file you have. I'm pretty sure it's the only working mode gcc and clang have, so changing build system can't help here.
Yeah that philosophy is optimized for when you make a change in one or two files and then rebuild - only the files you changed need to be rebuilt. If you wanted to, you could pass all source files to the compiler every time, but that means a single change requires recompiling everything. For small projects that's usually much more efficient than compiling each file separately.
What's the word for when someone says something that's completely true but when put in context it makes absolutely no sense whatsoever? Because that's exactly what happened here. Unix Philosophy™ doesn't make incremental compilation any easier - in fact, it makes it a little bit harder, since all reusable intermediate artifacts have to be separate named files.
-
@benjamin-hall said in Intel making us slow down:
Question--if it's the syscalls that will be slowed down (by 20-30%?), what percentage of the total time is spent in syscalls for an average (non-compiling) user? There's a big difference in taking 1.2x as long on 0.000001% of the workload (negligible overall) and taking 1.2x as long in 90% of the workload.
Are there workloads that depend heavily on syscalls? Small constant file access, but what types of normal uses do lots of those? This is an area I know really nothing about.
Every file read is a syscall. Every allocation is a syscall. Every device access is a syscall. Every task switch is a syscall. Any kind of interaction with the operating system usually requires a syscall or ten. Every kind of application will suffer greatly, except bitcoin miners.
-
@pie_flavor said in Intel making us slow down:
@bb36e you do realize that's no different from a DLL missing at runtime, right?
Yes...?
-
@gąska said in Intel making us slow down:
Any kind of interaction with the operating system usually requires a syscall or ten. Every kind of application will suffer greatly, except bitcoin miners.
-
@boomzilla said in Intel making us slow down:
@masonwheeler said in Intel making us slow down:
@weng said in Intel making us slow down:
@lolwhat Nah, I'll roll with incompetence as the root cause here.
I'll be switching back to AMD at home for the foreseeable future.
Does this even affect home systems? (ie. do you and I have any real reason to be concerned about our home PCs?) From what I've read, it appears that this is an issue that's mostly a headache for cloud servers and other shared systems.)
When your OS gets updated your Intel machine will run more slowly.
One more reason not to update my OS.
-
@createdtodislikethis More time to shoot aliens!
-
@gąska said in Intel making us slow down:
@cvi said in Intel making us slow down:
If you're doing tons of small IO and stuff, you might be fucked.
*coughc++programmingcough*
Yeah, this ought to be fun...
-
Oh hey, Azure, what's up?
Oh goody, they did send me an email saying they were going to do "planned maintenance".
Zoom! Enhance!
In other words "We don't think things are worse, but just in case, sign up with Free* thing!"
Status: Putting in a Jira to harden the servers against unexpected reboots...
-
@tsaukpaetra said in Intel making us slow down:
"planned maintenance".
Goddam it's taking forever to create some of these machines...
Whatever, I'll leave it for now, I'm hungry...
-
@masonwheeler said in Intel making us slow down:
In fact, I wouldn't be surprised to see AMD fall when the news becomes public, and maybe NVIDIA, because they're in the same sector and that's how automated trading systems work, for better or for worse.
Yeah, stock market.
We're pretty good at taking customers away from our competitors, as our product essentially works and our competitors tend to have their heads up their respective backsides. We'll post good numbers and our stock will go up.
Then our competitors, having lost customers to us, will post bad numbers. Our stock will go down, because sector weakness.
-
@gąska said in Intel making us slow down:
Every allocation is a syscall
BZZT. Nope. Unless you're allocating an entire page of RAM for each variable, most memory allocations in a program never touch kernel mode code.
-
@ben_lubar said in Intel making us slow down:
@gąska said in Intel making us slow down:
Every allocation is a syscall
BZZT. Nope. Unless you're allocating an entire page of RAM for each variable, most memory allocations in a program never touch kernel mode code.
All I know is that instead of taking 5 minutes to destroy and spin up 16 Azure VMs, it took almost an hour. Will try again tomorrow on the dev resource group just to make sure it wasn't because they were mass-rebooting everyone.
What's hilarious is that there's no way rebooting any of our VMs would change anything, they're read-only stateless images that get reset on boot, so unless they were actually rebooting so that the instances could be stood up on an updated hypervisor, they're lying through their teeth...
-
Spectre affects ALL processors, including Intel, AMD, and ARM. It can't be fixed in software like Meltdown. Time to upgrade...
-
@benjamin-hall said in Intel making us slow down:
Question--if it's the syscalls that will be slowed down (by 20-30%?), what percentage of the total time is spent in syscalls for an average (non-compiling) user? There's a big difference in taking 1.2x as long on 0.000001% of the workload (negligible overall) and taking 1.2x as long in 90% of the workload.
Are there workloads that depend heavily on syscalls? Small constant file access, but what types of normal uses do lots of those? This is an area I know really nothing about.
On linux, (and probably other unixes) you can compare the amount of time spent in syscalls versus the amount of time spent in user code by comparing the 'user' and 'system' CPU usage numbers. It can be obtained, among other methds, as follows:
$ time du -s 7166699 . real 0m0.635s user 0m0.047s sys 0m0.563s
Here, 10 times as much time was spent doing syscalls than in userspace code.
Note, however, that the number of syscalls, pagefaults, context switches, etc is probably more relevant than the actual time spent in them.
-
@gąska said in Intel making us slow down:
so changing build system can't help here
Actually it might. GNU Make is well known to make umptillions of
stat
calls trying to remake various files using swaths of obscure implicit rules defined by default and that can actually be significant overhead in a build—as in build that needs to do nothing taking a couple of seconds—unless you take care to disable the default rules, which almost nobody ever does. Since this overhead is already mainly kernel entries and exits, it will take the biggest hit. CMake + ninja is much faster because it only looks for sources you actually tell it about.
-
@lb_ said in Intel making us slow down:
Oh dear, marketing got its hands on it...
Why is it called Meltdown?
The bug basically melts security boundaries which are normally enforced by the hardware.Why is it called Spectre?
The name is based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time.
-
As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.
Why?
Let me set the scene: It’s late in 2013. Intel is frantic about losing the mobile CPU wars to ARM. Meetings with all the validation groups. Head honcho in charge of Validation says something to the effect of: “We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times… we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our competition is moving much faster than we are” - I’m paraphrasing. Many of the engineers in the room could remember the FDIV bug and the ensuing problems caused for Intel 20 years prior. Many of us were aghast that someone highly placed would suggest we needed to cut corners in validation - that wasn’t explicitly said, of course, but that was the implicit message. That meeting there in late 2013 signaled a sea change at Intel to many of us who were there. And it didn’t seem like it was going to be a good kind of sea change. Some of us chose to get out while the getting was good. As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.
Source: https://danluu.com/cpu-bugs/ found in a slashdot comment
-
@masonwheeler said in Intel making us slow down:
Intel's stock will take a big hit when the news breaks
And even bigger when the legal departments at Microsoft, Amazon and Google get their gears up to speed and sue them—cloud services will pretty surely be impacted and the losses can be counted quite easily there.
-
My father, who is still on Windows XP, is all smug right now about the relative speed increase. The bastard.