But when it grabs O2 it makes some toxic compounds. The plant spends a lot of energy on detoxifying these compounds. From what they said in the article they hacked out this detoxifying system and put in a more efficient detoxifying system which uses less energy. That extra energy is not used to make the plant grow faster and bigger.
The purpose of unreal mode was to access more memory while still being able to quickly call real mode DOS/BIOS services and device drivers. Since in this case it is the BIOS and you have to go into protected mode to set up unreal mode, might as well just stay in protected mode and access all of memory that way.
My example is not highly unlikely. It happens all the time with interrupts. If a disk read completes for another process the kernel has to flush the lower address space TLBs. But I think you're right in that it doesn't need to happen on entry to a syscall but it might need PCID to selectively flush eficiently.
I know about the virtual address space layout and the hole in the middle. It's probably on of the factors in the AMD IRET bug I ran into on Ryzen.
I don't believe the PCID feature is the cause of the bug. The cause was that Intel check privileges at instruction retirement and not at the start of the speculative operration. PCID would mitigate the performance penalty of the fix as the kernel wouldn't have to flush all TLBs.
The TLB maps the virtual to physical addresses. Leaving stale ones is a bad idea which can lead to memory corruption.
Take this example. User mode page table maps virtual address 0x1000 to physical 0x500000. Switch to kernel mode and the kernel mode page table maps 0x1000 to physical 0x600000 for either it's own data or maybe another processes data. So the kernel goes to write to 0x1000 and the processor goes "hey, I have that cached" and proceeds to overwrite 0x500000 instead of the 0x600000 the page tables say it should.
Now there is a feature called PCID where not all the TLB entries need to be flushed. That can reduce the performance hit of the fix.
This totally removes the benefits of L1-L3 caches on the CPU
No, those caches work on physical addresses so the page table mappings have no effect. It's the TLB caches which caches the virtual to physical address mappings that are flushed.
I'm much more surprised this can't be fixed in microcode
Microcode can't fix everything. It's generally limited to how instructions get executed. The virtual memory system can't be patched by microcode. Even if it could the slowdown would be 10s to 100s of times worse than the slowdown caused by this fix. This is a fundamental flaw in the virtual memory protection circuitry.
It's not the flaw that causes the slowdown, it's the fix that causes the slowdown. You are correct that it has to do with the TLB cache because they are flushed after CR3 is updated to the new page table directory at each switch from user mode to kernel mode and back.
Virtual memory is just the mapping of a virtual address space to a physical address space. Paging is the swapping out of memory to disk so you can allocate more than you physically have. Virtual memory is what's commonly used to implement paging.
This bug is a flaw with the virtual memory protection mechanism that stops user code from reading kernel data.
I don't think you understand how drastic this fix is. Every time a user mode to kernel mode transition happens and every time a hardware interrupt happens, the entire page table directory layout has to be switched. This means all the TLB caches are flushed as well and that's where the main performance hit comes from.
So if you're doing something like crypto currency mining you're not going to see much of a hit. But if you're doing a lot of I/O (file servers, database servers, web servers, etc.) you're going to see that 25-35% performance hit.
And that's why hardware bugs are so serious. Sometimes you get lucky and it's a microcode update with no penalty. Sometimes it's a simple fix with barely any performance penalty. But sometimes you get unlucky and the fix hurts a lot and the only way to get the performance back is to swap out the hardware.
Nope. Page Table Isolation is the fix and not the fault. But isolating the userland and kernel page tables means you have to switch between them each time you go from user mode to kernel mode and back. This slows things down.
AMD CPUs don't have the bug where user mode can read kernel pages so does not require this isolation and the performance hit caused by enabling it. From the AMD email: "The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."
> At this moment you're the laughing stock of an entire classroom
Dear lord, you're a teacher?! Those poor students. Now we'll have even more members of society that have no respect for others and when someone doesn't agree with them they resort to insults instead of with a counter argument.
Or you're a student which means your teacher didn't do a good job.
If you're in America it would explain a lot of things however...
> and an example of delusion
So me saying that a byte is not always 8-bit qualifies a delusion? I gave you two examples to back up my argument yet you're the one who failed to provide something that discredits them.
Constantly repeating "They don't exist" over and over again is what qualifies you as delusional.
> Do us all a favor and keep coming back.
Nah. You didn't give me much to work with this reply. I think you're running out of new ideas in your trolling.
Going to turn off my notifications and give slashdot a break. At least they ban people like you on other forums.
> Your mistake is indicative of your thought process, riddled with errors.
I have made no factual errors. I may have misread what you wrote but that was your fault for choice of words. My reply however was clear in what I was talking about.
> Everywhere? Period now equals everywhere, or does period equal the context of the conversation?
To any other person fluent in English, yes. That's what it sounds like. Here are some examples:
"There are 8 bits in a byte, according to the HDMI specification." - Very specifically in the context of the conversation.
"There are 8 bits in a byte." - Slightly ambiguous to the context but a reader can assume you were talking about HDMI.
"There are 8 bits in a byte, period." - Context now looks like it's also outside the conversation and that your statement applies everywhere. That a byte is never ever anywhere not 8 bits. But now that I called you out on it you're trying to retcon that you were only referring to HDMI.
You could have corrected me right away that you were only talking about HDMI. But instead of doing that you asked me for an example of a 9-bit computer.
> There is no 8-bit implementation in HDMI, or any other technology, modern or otherwise.
You're making fun of my spelling mistakes yet you make mistakes like that. LOL.
> You are representative of a failed American education and you're bitter for it
I'm not an American.
> Go share with the world your 9-bit philosophy.
Again, what's with this obsession with thinking that I have a 9-bit philosophy? You should see a psychiatrist about that.
I gave you one example of a system that had 9-bit bytes. I only did that because of your demands for an example, not because of your delusion that I need to evangelize 9-bits.
I said that 12-, 14- and 16-bit byte DSPs exist currently. I don't care that 9-bit byte machines don't exist anymore. I said that a byte is not always 8 bits. I was not talking about HDMI when I wrote that. Why won't any of this sink into that thick skull of yours?
The most likely answer is that you're just trolling. I'll eventually stop replying when I get bored of you. I'm currently having fun with this so it doesn't matter if you're a troll or just have reading comprehension issues.
I made a spelling mistake. Big fucking deal. Doesn't affect my argument one bit (pun intended). I'm just laughing that you felt the need to devote half your reply to a spelling mistake.
> You can't even spell the word, how can anyone expect a logical thought from you.
And you can't spell the word bit: "9 but machine". How can I expect logical though from you! LOL!
> you're incapable of comprehending that your first post was a response to an actual implementation, and your response contained the statement that it could be an 8 or 9 bit byte.
Check again. I'm not the one who wrote 'There's an 8 (or 9) fold difference between "Gb" and "GB".'
When I read his post I took that to be a non-HDMI specific statement. Even if it wasn't you could have just wrote "The HDMI spec defines a byte as 8-bits". Yet you chose to make the statement that a byte is 8-bits everywhere and not just HDMI.
If that was not your intent with that statement then it is you who needs to brush up on your English language skills. You need to be more clear and specific in your writing. Also your reading skills are lacking as well. The first mention of 9-bit by me was "Some computers have 9 bit bytes." See the word computers in there and the absence of the acronym HDMI? How can you say I'm claiming that HDMI uses 9-bit bytes when I said computers.
> That was your fuck up, and that is what garnered my response.
And your fuck up was mixing up the other poster and myself. Your first response to me was "Care to cough up an example of a modern 9 but machine?" where I replied "No, but there are DSPs with 12, 14 and 16 as the smallest unit of memory."
Yet you got hung up on the 9-bit thing and can't get your mind off of it. Sad really, but very entertaining.
Yet you seem to be compelled to reply to me. I find that funny.
> You fucked up by spouting off about 9 bits and you haven't been able to recover.
You're under the mistaken impression I'm loosing this debate. You're also mistaken that my argument depends on 9-bit bytes existing.
> The Texas Instruments engineers are bright people, who are not part of this conversation.
But their work is. And they have a product where a byte is not 8 bits.
> They did not utilize 9 bit bytes
Read my previous post again, I never said TI used a 9-bit byte. I said they used a 16-bit byte. So if your statement of "There are 8 bits in a byte, period." is correct then the bright Texas Instrument engineers must be wrong for saying their product uses a 16-bit byte.
> nor did anyone else for that matter.
Multics
https://en.wikipedia.org/wiki/... - "The standard C programming language requires that the size of the char data type be at least 8 bits,[3] and that all data types other than bitfields have a size that is a multiple of the character size,[4] so standard C implementations on 36-bit machines would typically use 9-bit chars, although 12-bit, 18-bit, or 36-bit would also satisfy the requirements of the standard."
https://isocpp.org/wiki/faq/in... - "The C++ language guarantees that a char* (char pointers) can address individual bytes." and "Another valid approach would be to define a “byte” as 9 bits"
> In the future, feel free to sling your garbage as it pertains to any real byte implementation.
I just gave you an example where a byte was not 8 bits but you chose to reply right away with insults instead of actually reading what I wrote about a product that uses 16-bit bytes.
Even if an architecture that used a 9-bit byte never existed it doesn't matter. My argument was that a byte is not always 8-bits. The 16-bit byte DSP I mentioned proved that I was correct.
I have no idea why everyone is complaining about systemd. I've encountered absolutely zero issues with systemd after the transition from Debian to FreeBSD.
Demeaning your opponents. So when you can't win with facts, you try to win with insults. It does shows me what kind of person you are however.
While 32-bit bytes might be non-existent, 16-bit bytes are not: http://www.ti.com/lit/ug/spru2... . Check out section 5.3. Here's the note from the bottom of it:
Note: C55x Byte is 16 Bits
By ISO C definition, the size of operator yields the number of bytes required
to store an object. ISO further stipulates that when sizeof is applied to char,
the result is 1. Since the C55x char is 16 bits (to make it separately address-
able), a byte is also 16 bits. This yields results you may not expect; for exam-
ple, sizeof (int) == 1 (not 2). C55x bytes and words are equivalent (16 bits).
Guess the engineers at ISO and Texas Instruments are full of crap as well.
Ah, the next stage of the debate where I'm called names. The pattern never fails. So I'm and asshole and an idiot. How nice.
In communications the term octet is used instead of byte. See https://en.wikipedia.org/wiki/... . The RFCs use it, the Ethernet standard uses it, etc.
Yes, you can say in the context of a discussion that bytes are 8-bits. But adding "period" to the end of your statement takes it outside that context and means that it applies everywhere in every situation.
And this context? Since the person you replied to wrote "when broadband providers get it wrong" the context also includes the internet. So if you can prove to me that every last device hooked up to the internet uses 8-bit bytes then fine. Otherwise go away.
There are 8 bits in a byte, period. Where did the 9 come from?
Nope. A byte is the smallest addressable unit of memory. Some computers have 9 bit bytes. An octet is always 8 bits and is used instead of byte in all the RFCs.
1. Demonstrated ability to stick with something for a while.
So require someone to waste 4 years of their life while not earning money and accruing debt just to prove they can stick with something. Nice.
I'd bet that a lot of people would be willing to accept a much lower starting salary if they didn't have to finance a student loan.
2. The average college grad is usually more literate than the average high school grad. Better chance that you'll get an employee that can do basic math, speak properly to customers, etc.
That's a failure in the high school system if true. But the quote in the summary of the article says "even though for many jobs, the study found that a college degree yields zero improvement in actual performance"
3. Employers will get many applicants for any given job, so this will at least filter out SOME people. And of those that apply for the job, #1 above applies. Yes, it's lazy, but as long as you have more applicants than open positions, why not? (From the employer's point of view.)
Why not? Because it's a broken filter. The degree doesn't tell you that they're going to be good at their job, only that they're good at memorizing and passing tests. That and you're filtering out good candidates that don't have a degree.
It's way easier to find the right person when you haven't arbitrarily tossed a good chunk of the candidates away.
Slashdot Mirror
Nostalgic for Dial-Up during the BBS days? Yup!
Nostalgic for Dial-Up for Internet access? Hell no!
That last sentence should read: That extra energy is now used to make the plant grow faster and bigger.
They're talking about https://en.wikipedia.org/wiki/... which is used in the Calvin cycle when it grabs CO2.
But when it grabs O2 it makes some toxic compounds. The plant spends a lot of energy on detoxifying these compounds. From what they said in the article they hacked out this detoxifying system and put in a more efficient detoxifying system which uses less energy. That extra energy is not used to make the plant grow faster and bigger.
The purpose of unreal mode was to access more memory while still being able to quickly call real mode DOS/BIOS services and device drivers. Since in this case it is the BIOS and you have to go into protected mode to set up unreal mode, might as well just stay in protected mode and access all of memory that way.
Gah, slashdot munged my less than or equal operator and turned it into =
I suspect now that's what happened to AC's code.
Yes it is. The test condition is assignment and not a comparison.
If AC intended for it to be == then it would work fine until it ran on a single core machine. Then the loop would run 4 billion times.
So that comparison should be =
Next Year's Headline: "Top US Antitrust Official Uncertain of Need For Three Wireless Carriers"
My example is not highly unlikely. It happens all the time with interrupts. If a disk read completes for another process the kernel has to flush the lower address space TLBs. But I think you're right in that it doesn't need to happen on entry to a syscall but it might need PCID to selectively flush eficiently.
I know about the virtual address space layout and the hole in the middle. It's probably on of the factors in the AMD IRET bug I ran into on Ryzen.
I don't believe the PCID feature is the cause of the bug. The cause was that Intel check privileges at instruction retirement and not at the start of the speculative operration. PCID would mitigate the performance penalty of the fix as the kernel wouldn't have to flush all TLBs.
The TLB maps the virtual to physical addresses. Leaving stale ones is a bad idea which can lead to memory corruption.
Take this example. User mode page table maps virtual address 0x1000 to physical 0x500000. Switch to kernel mode and the kernel mode page table maps 0x1000 to physical 0x600000 for either it's own data or maybe another processes data. So the kernel goes to write to 0x1000 and the processor goes "hey, I have that cached" and proceeds to overwrite 0x500000 instead of the 0x600000 the page tables say it should.
Now there is a feature called PCID where not all the TLB entries need to be flushed. That can reduce the performance hit of the fix.
This totally removes the benefits of L1-L3 caches on the CPU
No, those caches work on physical addresses so the page table mappings have no effect. It's the TLB caches which caches the virtual to physical address mappings that are flushed.
I'm much more surprised this can't be fixed in microcode
Microcode can't fix everything. It's generally limited to how instructions get executed. The virtual memory system can't be patched by microcode. Even if it could the slowdown would be 10s to 100s of times worse than the slowdown caused by this fix. This is a fundamental flaw in the virtual memory protection circuitry.
It's not the flaw that causes the slowdown, it's the fix that causes the slowdown. You are correct that it has to do with the TLB cache because they are flushed after CR3 is updated to the new page table directory at each switch from user mode to kernel mode and back.
Virtual memory is just the mapping of a virtual address space to a physical address space. Paging is the swapping out of memory to disk so you can allocate more than you physically have. Virtual memory is what's commonly used to implement paging.
This bug is a flaw with the virtual memory protection mechanism that stops user code from reading kernel data.
I don't think you understand how drastic this fix is. Every time a user mode to kernel mode transition happens and every time a hardware interrupt happens, the entire page table directory layout has to be switched. This means all the TLB caches are flushed as well and that's where the main performance hit comes from.
So if you're doing something like crypto currency mining you're not going to see much of a hit. But if you're doing a lot of I/O (file servers, database servers, web servers, etc.) you're going to see that 25-35% performance hit.
And that's why hardware bugs are so serious. Sometimes you get lucky and it's a microcode update with no penalty. Sometimes it's a simple fix with barely any performance penalty. But sometimes you get unlucky and the fix hurts a lot and the only way to get the performance back is to swap out the hardware.
Nope. Page Table Isolation is the fix and not the fault. But isolating the userland and kernel page tables means you have to switch between them each time you go from user mode to kernel mode and back. This slows things down.
AMD CPUs don't have the bug where user mode can read kernel pages so does not require this isolation and the performance hit caused by enabling it. From the AMD email: "The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."
I'm still waiting for a TV with a true Quantum Dot display. That will beat the crap out of OLED.
The current quantum dot TVs are just LCD TVs with a QD enhanced backlight. But at lease those are letting Samsung perfect the quantum dot tech.
> At this moment you're the laughing stock of an entire classroom
Dear lord, you're a teacher?! Those poor students. Now we'll have even more members of society that have no respect for others and when someone doesn't agree with them they resort to insults instead of with a counter argument.
Or you're a student which means your teacher didn't do a good job.
If you're in America it would explain a lot of things however...
> and an example of delusion
So me saying that a byte is not always 8-bit qualifies a delusion? I gave you two examples to back up my argument yet you're the one who failed to provide something that discredits them.
Constantly repeating "They don't exist" over and over again is what qualifies you as delusional.
> Do us all a favor and keep coming back.
Nah. You didn't give me much to work with this reply. I think you're running out of new ideas in your trolling.
Going to turn off my notifications and give slashdot a break. At least they ban people like you on other forums.
> Your mistake is indicative of your thought process, riddled with errors.
I have made no factual errors. I may have misread what you wrote but that was your fault for choice of words. My reply however was clear in what I was talking about.
> Everywhere? Period now equals everywhere, or does period equal the context of the conversation?
To any other person fluent in English, yes. That's what it sounds like. Here are some examples:
"There are 8 bits in a byte, according to the HDMI specification." - Very specifically in the context of the conversation.
"There are 8 bits in a byte." - Slightly ambiguous to the context but a reader can assume you were talking about HDMI.
"There are 8 bits in a byte, period." - Context now looks like it's also outside the conversation and that your statement applies everywhere. That a byte is never ever anywhere not 8 bits. But now that I called you out on it you're trying to retcon that you were only referring to HDMI.
You could have corrected me right away that you were only talking about HDMI. But instead of doing that you asked me for an example of a 9-bit computer.
> There is no 8-bit implementation in HDMI, or any other technology, modern or otherwise.
You're making fun of my spelling mistakes yet you make mistakes like that. LOL.
> You are representative of a failed American education and you're bitter for it
I'm not an American.
> Go share with the world your 9-bit philosophy.
Again, what's with this obsession with thinking that I have a 9-bit philosophy? You should see a psychiatrist about that.
I gave you one example of a system that had 9-bit bytes. I only did that because of your demands for an example, not because of your delusion that I need to evangelize 9-bits.
I said that 12-, 14- and 16-bit byte DSPs exist currently. I don't care that 9-bit byte machines don't exist anymore. I said that a byte is not always 8 bits. I was not talking about HDMI when I wrote that. Why won't any of this sink into that thick skull of yours?
The most likely answer is that you're just trolling. I'll eventually stop replying when I get bored of you. I'm currently having fun with this so it doesn't matter if you're a troll or just have reading comprehension issues.
> WTF?! You can't even spell the word
I made a spelling mistake. Big fucking deal. Doesn't affect my argument one bit (pun intended). I'm just laughing that you felt the need to devote half your reply to a spelling mistake.
> You can't even spell the word, how can anyone expect a logical thought from you.
And you can't spell the word bit: "9 but machine". How can I expect logical though from you! LOL!
> you're incapable of comprehending that your first post was a response to an actual implementation, and your response contained the statement that it could be an 8 or 9 bit byte.
Check again. I'm not the one who wrote 'There's an 8 (or 9) fold difference between "Gb" and "GB".'
When I read his post I took that to be a non-HDMI specific statement. Even if it wasn't you could have just wrote "The HDMI spec defines a byte as 8-bits". Yet you chose to make the statement that a byte is 8-bits everywhere and not just HDMI.
If that was not your intent with that statement then it is you who needs to brush up on your English language skills. You need to be more clear and specific in your writing. Also your reading skills are lacking as well. The first mention of 9-bit by me was "Some computers have 9 bit bytes." See the word computers in there and the absence of the acronym HDMI? How can you say I'm claiming that HDMI uses 9-bit bytes when I said computers.
> That was your fuck up, and that is what garnered my response.
And your fuck up was mixing up the other poster and myself. Your first response to me was "Care to cough up an example of a modern 9 but machine?" where I replied "No, but there are DSPs with 12, 14 and 16 as the smallest unit of memory."
Yet you got hung up on the 9-bit thing and can't get your mind off of it. Sad really, but very entertaining.
> You are not an opponent, you are nobody.
Yet you seem to be compelled to reply to me. I find that funny.
> You fucked up by spouting off about 9 bits and you haven't been able to recover.
You're under the mistaken impression I'm loosing this debate. You're also mistaken that my argument depends on 9-bit bytes existing.
> The Texas Instruments engineers are bright people, who are not part of this conversation.
But their work is. And they have a product where a byte is not 8 bits.
> They did not utilize 9 bit bytes
Read my previous post again, I never said TI used a 9-bit byte. I said they used a 16-bit byte. So if your statement of "There are 8 bits in a byte, period." is correct then the bright Texas Instrument engineers must be wrong for saying their product uses a 16-bit byte.
> nor did anyone else for that matter.
Multics
https://en.wikipedia.org/wiki/... - "The standard C programming language requires that the size of the char data type be at least 8 bits,[3] and that all data types other than bitfields have a size that is a multiple of the character size,[4] so standard C implementations on 36-bit machines would typically use 9-bit chars, although 12-bit, 18-bit, or 36-bit would also satisfy the requirements of the standard."
https://isocpp.org/wiki/faq/in... - "The C++ language guarantees that a char* (char pointers) can address individual bytes." and "Another valid approach would be to define a “byte” as 9 bits"
http://multicians.org/pg/mvm.h... - "To get 64K (256KB, using 9-bit bytes"
> In the future, feel free to sling your garbage as it pertains to any real byte implementation.
I just gave you an example where a byte was not 8 bits but you chose to reply right away with insults instead of actually reading what I wrote about a product that uses 16-bit bytes.
Even if an architecture that used a 9-bit byte never existed it doesn't matter. My argument was that a byte is not always 8-bits. The 16-bit byte DSP I mentioned proved that I was correct.
I have no idea why everyone is complaining about systemd. I've encountered absolutely zero issues with systemd after the transition from Debian to FreeBSD.
Demeaning your opponents. So when you can't win with facts, you try to win with insults. It does shows me what kind of person you are however.
While 32-bit bytes might be non-existent, 16-bit bytes are not: http://www.ti.com/lit/ug/spru2... . Check out section 5.3. Here's the note from the bottom of it:
Note: C55x Byte is 16 Bits
By ISO C definition, the size of operator yields the number of bytes required
to store an object. ISO further stipulates that when sizeof is applied to char,
the result is 1. Since the C55x char is 16 bits (to make it separately address-
able), a byte is also 16 bits. This yields results you may not expect; for exam-
ple, sizeof (int) == 1 (not 2). C55x bytes and words are equivalent (16 bits).
Guess the engineers at ISO and Texas Instruments are full of crap as well.
Ah, the next stage of the debate where I'm called names. The pattern never fails. So I'm and asshole and an idiot. How nice.
In communications the term octet is used instead of byte. See https://en.wikipedia.org/wiki/... . The RFCs use it, the Ethernet standard uses it, etc.
Yes, you can say in the context of a discussion that bytes are 8-bits. But adding "period" to the end of your statement takes it outside that context and means that it applies everywhere in every situation.
And this context? Since the person you replied to wrote "when broadband providers get it wrong" the context also includes the internet. So if you can prove to me that every last device hooked up to the internet uses 8-bit bytes then fine. Otherwise go away.
No, but there are DSPs with 12, 14 and 16 as the smallest unit of memory.
But the fact that 9 bit machines aren't being produced is irrelevant. They existed and some might still be operational.
While 8-bit bytes are the modern de-facto standard you can't say "There are 8 bits in a byte, period." and be correct.
There are 8 bits in a byte, period. Where did the 9 come from?
Nope. A byte is the smallest addressable unit of memory. Some computers have 9 bit bytes. An octet is always 8 bits and is used instead of byte in all the RFCs.
1. Demonstrated ability to stick with something for a while.
So require someone to waste 4 years of their life while not earning money and accruing debt just to prove they can stick with something. Nice.
I'd bet that a lot of people would be willing to accept a much lower starting salary if they didn't have to finance a student loan.
2. The average college grad is usually more literate than the average high school grad. Better chance that you'll get an employee that can do basic math, speak properly to customers, etc.
That's a failure in the high school system if true. But the quote in the summary of the article says "even though for many jobs, the study found that a college degree yields zero improvement in actual performance"
3. Employers will get many applicants for any given job, so this will at least filter out SOME people. And of those that apply for the job, #1 above applies.
Yes, it's lazy, but as long as you have more applicants than open positions, why not? (From the employer's point of view.)
Why not? Because it's a broken filter. The degree doesn't tell you that they're going to be good at their job, only that they're good at memorizing and passing tests. That and you're filtering out good candidates that don't have a degree.
It's way easier to find the right person when you haven't arbitrarily tossed a good chunk of the candidates away.