I'm trying to imagine the results for a similar review of computer science and computer architecture research from most universities.
Since there is nearly zero reproduction of results, limited validation, generally poor test content and few incentives to improve research quality I doubt the results would instill much confidence.
I'm wondering if we need to find a means of enforcing at least some level of fact checking and commentary from the mods. Simply re-posting this submission as is has turned into a giant flame fest because the research was crap. (As is a frighteningly large proportion of comp-sci & comp-eng research these days).
If the mods are decent then they should be able to take a moment to look through this, understand how much of a train-wreck it is and provide a bit of commentary to prevent the flame-fest or outright reject it. (I'm already on the site so a crap article isn't going to bring any additional add revenue. It will simply drive traffic elsewhere after the first few people identify it as crap.)
In other words... Human intelligence is the result of evolution. Shocking.
I sure hope there was more to this study that the submitter simply failed to mention...
I've been interviewing a lot of candidates at work for the past several months and the complete lack of knowledge in recent college grads scares the hell out of me. I've seen several people with 3.7-3.9 GPAs in comp sci from top10 (using us news rankings, yes I know they aren't perfect) engineering schools who couldn't do even basic tasks with pointers.
They spent all their time writing java. That's great if you need to write java but the fact that they didn't learn enough to be able to generalize their skills to other languages while still doing well in school does not day good things about that (and other) schools.
A pointer is not _that_ hard. You should at least be able to copy a linked list in an interview question. I used to have higher standards but the string off candidates I've seen lately has crushed all faith I once had.
You might expect a Power6 to be at a bandwidth disadvantage when compared to the x5560 but when you look at the memory bandwidth specs they're surprisingly close. Once you move up to Power7 you begin to see a big difference.
Xeon x5560 memory bandwidth/chip: 32 GB/s [1]
Power6 memory bandwidth/chip: 32 GB/s (??? This may be wrong. I see references to 50GB/s but I believe that's peak)
Power7 memory bandwidth/chip: 100 GB/s [3]
That person gets bumped to the middle of the resume pile.
The person on the top of the resume pile knows that VHDL, Verilog, SystemC, Specman, C, C++, Java, etc are all tools. Like all tools there are correct and incorrect times to use them (though there are plenty of instances when they're interchangeable).
The key part is that they know how to apply the tools to solve a problem, regardless of what the tools may be.
There are LOT of variables here. In some cases you absolutely cannot expect to make that much to start. In others you can expect that much or more.
I won't get into specifics but we've recently spent a few months trying to hire some recent grads & experienced candidates. - In a few cases we lost experienced candidates because their company (which was already paying them well above the salaries listed here) threw even more money at them to keep them on board. - Countless recent grads had already accepted offers above the range we're talking about here. One recent Masters grad was considering an offer from us that was above those listed in the story when he suddenly received a higher offer from a competitor.
All of the recent reports are claiming the "explosive device" contained PETN. For those of you that don't remember, PETN was a component in the bomb that brought down TWA 800, killing all 230 on board.
It wasn't a firecracker. Google "binary explosive"
Alternatively, there's a few videos on youtube discussing them. Here's the first one I came across that shows how to mix the powder & liquid parts: http://www.youtube.com/watch?v=fESo6JweU20
BMW speedometers read high but it's not due to a problem with the electronics. It is intentional and other replies have already stated why it's intentional.
If you go into the car's service menu (you can reach it with a goofy pedal combination, similar to the old Nintendo up-down-up-down-a-b-start) you can find a menu that presents the ACTUAL speed which is clearly separated from the REPORTED speed.
No, it hasn't. The problem is that much of the advances are in areas that aren't immediately obvious to most people. The various biological sciences and materials sciences are prime examples.
People notice the things that fundamentally change their life; the car, the airplane, the TV, etc. They don't notice someone rewriting a virus to perform something useful, nor the work with brain implants that when fed through a computer have controlled robotic limbs, nor someone "growing" nanowires in the lab, nor the fabrics that can stop a bullet while still being light and flexible enough to make comfortable clothing, etc.
IMO, anyone that doesn't see amazing tech popping up nearly every day is either stuck in the past or simply lacks any vision of the future.
True to a degree, though there is definitely money going towards working out the broad details of such a plan.
While many industries don't create plans that span more than a year or two, the business Intel is in all but requires it. It's absolutely a work in progress and is expected to change over the years but you'd be surprised how accurate these things can be. The broader vision of the Nehalem we see today is not that far removed from the vision of Nehalem they were discussing ~6 years ago.
Where did you see a suggestion there should be no software verification? Surely not in the parent. The question of the degree to which software verification is needed is entirely different than the question of whether "formal verification" is as effective as people who haven't worked with it believe.
I'm simply stating that formal verification isn't perfect. Having worked with it personally I have seen the majority of people simply take what it says on faith because they don't understand the process. Simple rules of thumb that people use to attenuate their "normal" verification expectations are often thrown out the window the first time they work with "formal" verification. A frequent reason is because they hear that it uses math - despite the fact that many forms of it use no more math than any other form of verification - and of course "math can't be wrong" when you're an engineer.
Formal is simply another tool in the toolbox. As with the rest of the tools there are certain instances in which it makes a lot of sense and others where there is something better. Having worked with it in the past I see a story claiming that an entire kernel was "formally verified" and the first thing that comes to mind is a question of how many bugs they missed by not using all their tools.
Just because someone did a formal proof doesn't mean it's correct, bug-free, etc. That's obviously the intention but just as people make mistakes when writing the initial code, people also make mistakes when doing the formal proofs.
Formal has been used for various pieces of hardware verification for a while. It's fairly easy to find examples of very real bugs that made it past formal.
The most famous one is probably the old, infamous Intel FDIV bug. Bob Colwell (PPro, P2, P3, P4 Chief-Architect) gave a talk at Stanford back in 2004 and one of the interesting slides brought up the FDIV bug and how it was "formally proven" but the formal proof was wrong.... Oops.
(You can find video of the talk online - great talk - check it out)
If this keeps up, pretty soon we'll be able to watch the Star Wars trilogy unfold through a telescope! It may have happened "a long time ago" but since it was "far far away" the speed of light may let us catch it.
Someone call me when they're able to spot the Death Star:)
A "tax loophole" is another term for "tax law." If you don't like the law, change it instead of bitching and moaning when someone follows the law.
Every one of you use "tax loopholes" when you take tax deductions, shelter money away in retirement accounts, etc. Using your logic, every one of you are "greedy bastards."
Much of the industry appears to be shifting towards Verilog but VHDL is still very common and is not going to disappear any time soon. If I had to make that decision I'd most likely choose Verilog because of this but it's not a simple, clear-cut choice.
When I used to teach Verilog to college seniors & grad students I saw the syntax similarity to C as a problem for many students. Every one of them had a strong programming background and were used to the sequential nature of software. When you let them loose with some of the Verilog constructs it will take a while for most of them to understand the parallel nature of what the language is describing - I can't begin to count the number of times I saw someone try to 'call' a piece of hardware as a process or part of a for-loop as if it magically appeared to calculate a single result and then vanished into never-never land. Blocking & non-blocking assignments will also cause countless headaches. So will the ease at which you can throw down massive amounts of hardware with a few simple lines of Verilog. You can and will see students make similar mistakes with VHDL but I believe the syntax differences can help limit the problems.
Ultimately, if the students need to use one in their career they will also need to use the other. No matter which one you choose they will easily be able to pick up the other as long as they understand what the HDL is truly describing.
Slashdot Mirror
A skeleton key / lever lock key from the early 1900s that belonged to my grandfather and a Sauber BMW F1 leather loop
I'm trying to imagine the results for a similar review of computer science and computer architecture research from most universities.
Since there is nearly zero reproduction of results, limited validation, generally poor test content and few incentives to improve research quality I doubt the results would instill much confidence.
I'm wondering if we need to find a means of enforcing at least some level of fact checking and commentary from the mods.
Simply re-posting this submission as is has turned into a giant flame fest because the research was crap. (As is a frighteningly large proportion of comp-sci & comp-eng research these days).
If the mods are decent then they should be able to take a moment to look through this, understand how much of a train-wreck it is and provide a bit of commentary to prevent the flame-fest or outright reject it. (I'm already on the site so a crap article isn't going to bring any additional add revenue. It will simply drive traffic elsewhere after the first few people identify it as crap.)
Yes, yes. I know. That isn't what our mods do...
Maybe it's time they started...
It sounds like they have too much time on their hands. Perhaps they are overstaffed and in need of some headcount reductions in order to regain focus.
In other words... Human intelligence is the result of evolution. Shocking. I sure hope there was more to this study that the submitter simply failed to mention...
What they wont learn is exactly what worries me.
I've been interviewing a lot of candidates at work for the past several months and the complete lack of knowledge in recent college grads scares the hell out of me. I've seen several people with 3.7-3.9 GPAs in comp sci from top10 (using us news rankings, yes I know they aren't perfect) engineering schools who couldn't do even basic tasks with pointers.
They spent all their time writing java. That's great if you need to write java but the fact that they didn't learn enough to be able to generalize their skills to other languages while still doing well in school does not day good things about that (and other) schools.
A pointer is not _that_ hard. You should at least be able to copy a linked list in an interview question. I used to have higher standards but the string off candidates I've seen lately has crushed all faith I once had.
"Sony Updates PS3 Firmware To 3.56 To Stop Jailbreaking"
"Sony did not state that it would stop jailbreaking the console but we can only assume that it does."
You can only assume? Call me when you know. Until then stop wasting my bandwidth with your wild guesses.
You might expect a Power6 to be at a bandwidth disadvantage when compared to the x5560 but when you look at the memory bandwidth specs they're surprisingly close. Once you move up to Power7 you begin to see a big difference.
Xeon x5560 memory bandwidth/chip: 32 GB/s [1]
Power6 memory bandwidth/chip: 32 GB/s (??? This may be wrong. I see references to 50GB/s but I believe that's peak)
Power7 memory bandwidth/chip: 100 GB/s [3]
Hate to break it to you but POWER7 can dispatch 6 instructions per cycle as well.
That little fact was revealed last year during the Hot Chips 21 presentation.
That person gets bumped to the middle of the resume pile.
The person on the top of the resume pile knows that VHDL, Verilog, SystemC, Specman, C, C++, Java, etc are all tools. Like all tools there are correct and incorrect times to use them (though there are plenty of instances when they're interchangeable).
The key part is that they know how to apply the tools to solve a problem, regardless of what the tools may be.
There are LOT of variables here. In some cases you absolutely cannot expect to make that much to start. In others you can expect that much or more.
I won't get into specifics but we've recently spent a few months trying to hire some recent grads & experienced candidates.
- In a few cases we lost experienced candidates because their company (which was already paying them well above the salaries listed here) threw even more money at them to keep them on board.
- Countless recent grads had already accepted offers above the range we're talking about here. One recent Masters grad was considering an offer from us that was above those listed in the story when he suddenly received a higher offer from a competitor.
No, I was referring to TWA 800:
http://www.nytimes.com/1996/08/23/nyregion/readily-available-petn-is-easily-molded-and-hidden.html?pagewanted=1
All of the recent reports are claiming the "explosive device" contained PETN.
For those of you that don't remember, PETN was a component in the bomb that brought down TWA 800, killing all 230 on board.
"Firecracker" my ass...
It wasn't a firecracker. Google "binary explosive"
Alternatively, there's a few videos on youtube discussing them. Here's the first one I came across that shows how to mix the powder & liquid parts:
http://www.youtube.com/watch?v=fESo6JweU20
What makes the know-it-alls and bone-heads that work in the news any better than know-it-alls and bone-heads who don't?
Most media people you see day-to-day have the mistaken impression that they actually know WTF they're talking about. Unfortunately, they don't.
That's a ridiculously uninformed comment.
BMW speedometers read high but it's not due to a problem with the electronics. It is intentional and other replies have already stated why it's intentional.
If you go into the car's service menu (you can reach it with a goofy pedal combination, similar to the old Nintendo up-down-up-down-a-b-start) you can find a menu that presents the ACTUAL speed which is clearly separated from the REPORTED speed.
Why not? They certainly must have a much bigger carbon footprint than the family dog.
It goes to show that a company like IBM can function using a "minority" office suite.
That depends on how you define "function."
No, it hasn't. The problem is that much of the advances are in areas that aren't immediately obvious to most people. The various biological sciences and materials sciences are prime examples.
People notice the things that fundamentally change their life; the car, the airplane, the TV, etc. They don't notice someone rewriting a virus to perform something useful, nor the work with brain implants that when fed through a computer have controlled robotic limbs, nor someone "growing" nanowires in the lab, nor the fabrics that can stop a bullet while still being light and flexible enough to make comfortable clothing, etc.
IMO, anyone that doesn't see amazing tech popping up nearly every day is either stuck in the past or simply lacks any vision of the future.
True to a degree, though there is definitely money going towards working out the broad details of such a plan.
While many industries don't create plans that span more than a year or two, the business Intel is in all but requires it. It's absolutely a work in progress and is expected to change over the years but you'd be surprised how accurate these things can be. The broader vision of the Nehalem we see today is not that far removed from the vision of Nehalem they were discussing ~6 years ago.
Where did you see a suggestion there should be no software verification? Surely not in the parent. The question of the degree to which software verification is needed is entirely different than the question of whether "formal verification" is as effective as people who haven't worked with it believe.
I'm simply stating that formal verification isn't perfect. Having worked with it personally I have seen the majority of people simply take what it says on faith because they don't understand the process. Simple rules of thumb that people use to attenuate their "normal" verification expectations are often thrown out the window the first time they work with "formal" verification. A frequent reason is because they hear that it uses math - despite the fact that many forms of it use no more math than any other form of verification - and of course "math can't be wrong" when you're an engineer.
Formal is simply another tool in the toolbox. As with the rest of the tools there are certain instances in which it makes a lot of sense and others where there is something better. Having worked with it in the past I see a story claiming that an entire kernel was "formally verified" and the first thing that comes to mind is a question of how many bugs they missed by not using all their tools.
Just because someone did a formal proof doesn't mean it's correct, bug-free, etc. That's obviously the intention but just as people make mistakes when writing the initial code, people also make mistakes when doing the formal proofs.
Formal has been used for various pieces of hardware verification for a while. It's fairly easy to find examples of very real bugs that made it past formal.
The most famous one is probably the old, infamous Intel FDIV bug. Bob Colwell (PPro, P2, P3, P4 Chief-Architect) gave a talk at Stanford back in 2004 and one of the interesting slides brought up the FDIV bug and how it was "formally proven" but the formal proof was wrong.... Oops.
(You can find video of the talk online - great talk - check it out)
If this keeps up, pretty soon we'll be able to watch the Star Wars trilogy unfold through a telescope!
It may have happened "a long time ago" but since it was "far far away" the speed of light may let us catch it.
Someone call me when they're able to spot the Death Star :)
Since most people here seem to have forgotten....
A "tax loophole" is another term for "tax law." If you don't like the law, change it instead of bitching and moaning when someone follows the law.
Every one of you use "tax loopholes" when you take tax deductions, shelter money away in retirement accounts, etc. Using your logic, every one of you are "greedy bastards."
(Commence the -1's in 3... 2... 1...)
Much of the industry appears to be shifting towards Verilog but VHDL is still very common and is not going to disappear any time soon. If I had to make that decision I'd most likely choose Verilog because of this but it's not a simple, clear-cut choice.
When I used to teach Verilog to college seniors & grad students I saw the syntax similarity to C as a problem for many students. Every one of them had a strong programming background and were used to the sequential nature of software. When you let them loose with some of the Verilog constructs it will take a while for most of them to understand the parallel nature of what the language is describing - I can't begin to count the number of times I saw someone try to 'call' a piece of hardware as a process or part of a for-loop as if it magically appeared to calculate a single result and then vanished into never-never land. Blocking & non-blocking assignments will also cause countless headaches. So will the ease at which you can throw down massive amounts of hardware with a few simple lines of Verilog. You can and will see students make similar mistakes with VHDL but I believe the syntax differences can help limit the problems.
Ultimately, if the students need to use one in their career they will also need to use the other. No matter which one you choose they will easily be able to pick up the other as long as they understand what the HDL is truly describing.