Assuming all questions had four options and the answers were uniformly distributed, then yes, the "expected value" is 15. But, surely you recall that the standard deviation of the binomial distribution is sqrt(60*(1/4)*(3/4)) = sqrt(11.25) = approx 3.35. So to get 10 puts you less than 1.5 stdev from the mean. For normally distributed data (which I would expect the scores for such a test with random answer selection), 68% of the results are within 1 stdev, and 95% are within 2.
So, a score of 10 doesn't seem out of place at all. (And this is all high-school level stats, mind you, sticking to the Probability 101 theme here.)
There are some pieces of code at work where the "constantly switch off projects and tasks" has been applied almost as an anti-pattern. Glue scripts with code dating back 15 years, where probably a dozen or more different folks have gone in and made their "one little tweak", trying not to disturb the rest. We end up with a script with 50 flags, and who knows what subset of those flags is still relevant or really works.
Every so often, someone goes in there and removes some of the cruft, but it is still the result of dozen or more people hacking and slashing to "get something working." Half or more of the "comments" in the code are commented-out old versions of some code path that had been tweaked for the present need. Scar tissue abounds. Looking at the script now, I see one if-statement where all the code in the body of the if-statement is commented out, but the if itself isn't. Lovely! Tons of short blocks of code commented only with a cryptic test-case ID that triggered the need. (Note: These aren't test cases for the script, these are test cases the script loads into something else.)
And yet, the code continues to function. And it does get tested. The particular script I'm thinking of that's the most egregious offender sits at the heart of a verification flow: It launches the design under test.
Where I work, we've mined many products which failed to reach the market for good ideas. Often, there were many good ideas in there, it was just the package as a whole that didn't work out. (Either too early, too late, too big or too small.) But, we've also had good continuity among our key folks (myself included), so that probably explains why it ends up working. We understood why we put those features in failed product X, and so we understand how they'd work in new, more viable product Y. We also understand at least something about why X failed, so we can try to avoid it on Y.
But again, that does rely on institutional memory to make it work.
Well, like I said in my followup "reply to self", it really does depend on the nature of the task. We don't have enough information to go on. The TI DSP cards do fill an interesting niche, though, and are a nice counterpoint to the Tesla cards in many applications.
Really, you need to just get some demo tools for a couple platforms, do some benchmarks, and see how each platform feels. You'd be silly to drop $10,000 - $15,000 on a server without first running some benchmarks on a smaller version of what you intend to buy, as well as collecting some data on how the results on the small system scale to the proposed larger system.
Proposing a solution and working backwards only truly works for constructing those initial benchmarks.
I personally try to tackle a big new thing regularly. I started realizing I needed to do that around 5 years ago, right around when I hit the 10 year mark at work. Until then, I was largely a C/ASM programmer, with a lot of experience in that area, but not so much outside it. I realized I was in danger of becoming a one-trick pony, programming-wise. Since then, I've gained expertise in System C, Perl, Moose, C++, OO design patterns, compiler theory, etc. Currently I'm taking those free Stanford AI and ML courses, and teaching myself ARM assembly language. I'll probably tackle Python someday.
My job title isn't programmer at all, and I'm not even a software engineer. I'm a processor/SoC architect part of the time, a sort-of DV person part of the time (really, a cross-check on our DV), and a jack-of-all-trades the rest of the time. I do write a lot of software, either for analysis, or automation, or verification. (Hence all the Perl, automating the daily doldrums.) But, that software is all to support my other activities, such as performance analysis, DV, simulation, etc.
Really, in the end, I'm a problem solver. And I've made it my personal goal to be as good a problem solver as I can be, and that means boning up on a wide array of stuff, regularly. If someone asked me "What programming language do I need to learn to get a high paying job?" I'd say "Whatever people are paying money for today, and keep in mind the answer will be different tomorrow. Prepare to keep learning new languages and skills."
And you're right: The vast majority out there don't think like that at all. It's like pushing a wet noodle trying to get folks to learn new skills or better ways of doing things.[*] Or, they will begrudgingly learn it if someone hand-holds them through the whole process. Come ON people! Show some initiative! More than once I've been stymied by "Oh, we don't know how to do that, and so and so who does is too busy to look at it," only to break the deadlock by figuring out how to do it myself. (Often, it was surprisingly easy.)
That difference in attitude is why I think I won't have a problem for the next 15 years of my career. (I just hit the 15 year mark this year.) Some of my coworkers, not so much.
[*] Anecdote from a friend in another industry: She works in a group that handles documentation for a healthcare products company. She was telling me how her coworkers insert page breaks in their Word documents: Press "enter" enough times to get to a new page. And they refuse to do differently. "Insert Page Break" is "too much" for them. It's not just the programming industry. It's everywhere.
I should add also that depending on the nature of your task, it may perform closer or further from the "peak" performance on the DSP vs. on a GPU. So a single Tesla 1 TFLOP card may not perform the same as a single DSP 1 TFLOP card.
There's some high-powerd PCI cards filled with TI DSPs that you can get. Here's an article describing some of them. In terms of power efficiency per unit of work, the DSPs blow the doors off the main processor and the GPUs. Each DSP on the chip can do 16 single precision or 4 double precision floating point operations per cycle, at around 1GHz, and they're programmable in C/C++.
Relevant quote:
Kenneth Nesteroff, business development manager for multicore processors at IT's DSP Systems unit, tells El Reg that in the first quarter, Advantech will come out with a full-length PCI-Express card that will deliver around 1 teraflops of single precision performance at a cost of around $2,000 and within a 110 watt thermal envelope.
Buy 5 of these and you're only at 550W, $10,000 and 5 TFLOPs.
Who says they'd find out? All they'd know is that you used their software to open up a port. And, given that Conficker landed with a thud to begin with, perhaps the spooks had taken over its C&C infrastructure and was pretty certain it had control over it. If you can get someone else to do your dirty work without them realizing they're doing it, it's harder to trace back to you.
It also seems possible that whoever wrote Stuxnet had pulled apart one or more pre-existing worms out there and decided to commandeer one, or at least collect intelligence from it. I mean, if someone has already done a bunch of dirty work for you, and you can piggy back on it "safely", then you have an effective vector for fast initial deployment.
The current carrying capacity of the wires would need to be about 30 times larger, though, to deliver the same amount of power. That's pretty huge. To go to 12v everywhere, you'd need huge current-carrying wires everywhere (think "as big as your car battery cables or bigger"). To carry 1kW through a 380V line, you only need to handle 2.6A. To carry 1kW through a 12v line, you need to handle 83A. And that's just one beefy server.
Now think of your house wiring. Outside of your major appliances, where do you see runs higher than 15A or maybe 30A? There's a reason high voltage is good.
The problem with DC back in Edison's day was that you couldn't easily step it up or down. DC doesn't have higher losses than AC at the same voltage. In fact, DC radiates less energy away than AC does, and is therefore more efficient.
Ohmic losses all come down to I^2 * R. R is the resistance of the cable, and I is current. To deliver a given amount of power, you have to have a certain V*I. To reduce Ohmic losses, then, you have to reduce the amount of current, which means going up in voltage.
Incidentally, that's also what's driving automobile manufacturers toward 48v instead of 12v, since it would cut the current from the battery by a factor of 4, thereby reducing the amount of loss in the wiring by a factor of 16. That means you can use smaller wires to deliver the same amount of power, safely.
It's a Pentium in as much as they named it "Pentium," much like a Ford Taurus of today is just as much a Ford Taurus as one they made 20 years ago, even though they have no parts in common. It's a Taurus because Ford named it that.
The Intel Atom probably has more in common with the original P54C than the Pentium Pro did.
Hmmm... processors do do more work per clock nowadays as compared to 12 years ago. And, they do it at waaaaaaaay less power and cost. Think about your huge many-fanned nearly 1kW rig from the turn of the millennium vs. the cramped space of a 1U slot pulling maybe 100W. This ain't your father's Pentium.
*shrug* Probably. My main point was that there's a ton of compute power lying between any two endpoints of an SMS, and that the magnitude of the problem (grepping for 1600 bad words) is very, very, very small compared to that, even if you absurdly overestimate the cost by several orders of magnitude.
BTW, I realize this is Pakistan that we're talking about, not the US. I just used the US numbers to get an initial order of magnitude to get in the ball park for the number of SMSes/sec a given cell tower might see, on the presumption that a cell tower in the US has a similar amount of work to do per subscriber as a cell tower in Pakistan.
What, you think they're going to do this on a Commodore 64?
I looked it up, and folks in the US send 80 billion SMSes per month. That works out to about 30k SMSes/sec on average across the entire United States. Now, I realize that certain times of day are more likely to have SMSes than others, so let's say, to a first order, the peak rate of SMSes is 100k/sec. Now divide that among all the cell towers, understanding that some will be busier than others.
Let's say a given cell tower has to process 100 SMSes a second, each at the full 160 character limit. That's 16kB/s. Let's say each word take 1000 cycles to test for, which should be on the high side since it assumes you can't use, say, a trie to take advantage of common word roots, or use pattern matching accelerators (which are quite common in this space). 16kB/s * 1000 * 1600 = 25.6Gcyc/sec. That sounds like a lot, but it isn't.
A single board in one of these cellular base stations has literally dozens of processor chips, most with multiple cores, running in the GHz range. And that's just one board. My employer sells a chip in this space which crunches away 10Gcyc/sec across all of its 8 processors, and our customers put dozens of these on each board.
On GSM networks, SMSes are control channel messages. They go via a low bandwidth side channel that is nowhere near as compute-intensive as the main voice channel. If you're provisioned to handle a certain number of phone calls, you're more than adequately provisioned to handle SMSes and the corresponding filtering, as long as you do the filtering at the base station.
What are you doing on it during that time? The processor, baseband and RF circuits also suck up a fair juice. That PDF I linked above shows GSM consuming around 600mW during GPRS and WiFi consuming around 700mW when in use on the phone they analyzed. I'd expect other phones to be similar. 3G is supposedly much worse at draining batteries. Dunno about CDMA/LTE, but I would imagine they'd also be in the half-watt to 1 watt range, to venture a first-order guess.
If you're just playing games, then it's just the CPU, RAM and display sopping the battery.
Is the display really that much of a hog on a cell phone? Those numbers sound like laptop numbers, but I thought we were talking cell phones.
My phone has a battery that holds around 1300 mAh at 3.7v. That means I can draw 4.8W for 1 hour. If my phone's display really sucked down even 10W, then I wouldn't be able to have the display on for more than about 28 minutes total, which doesn't match my experience at all. I regularly browse the web from my phone for a half hour at a time, without making much of a dent in the battery.
A quick scan through this paper suggests backlight power for the phone they analyzed tops out at 414mW, and the LCD display power ranges from 33.1mW to 74.2mW. If you drop the brightness back just a few notches, the total display power is around a quarter Watt or so, which sounds far more reasonable.
I don't think Intel is standing still on power consumption. Their desktop CPUs are hogs, sure, but they can bring a lot of engineers to bear optimizing Atom-derived products. (We might get an early read from Knight's Corner, actually, although I expect it to still be on the "hot" side. I'm waiting to hear more about it.) Also, ARM's latest high-end offerings (including the recently announced A15) aren't exactly as power-frugal as some of their past devices. In the next couple years, I think the scatter plot of power vs. performance for ARM and x86 variants will show a definite overlap in the mix, with some x86s pulling less power than some ARMs.
But, where in all of that "non-specialization" did you learn about DNS records, whatever the hell Active Directory does, and TV trivia?
Consider TV shows: There are sci-fi geeks that are into Trek, geeks that are into Babylon 5, geeks that are into Doctor Who, geeks that are into Battlestar Galactica, geeks that are into Firefly, etc. If you draw a Venn diagram of all these, I think you'd find significant regions of non-overlap, which implies a certain amount of specialization. (Actually, I'm not sure you could draw the Venn diagram accurately on a planar surface unless you break up some of the bubbles.)
Are geeks required to limit themselves to late-70s/mid-80s circuitry and low level assembly programming to be considered geeks? That notion is absurd. There were geeks before TTL existed, and there are geeks today that were born after CPUs started their steady march from 3.3v down to sub-1v today, leaving behind old school TTL. Geekdom is a form of specialization, and there will always be subdomains within geekdom. That's what I mean by specialization.
Slashdot Mirror
Assuming all questions had four options and the answers were uniformly distributed, then yes, the "expected value" is 15. But, surely you recall that the standard deviation of the binomial distribution is sqrt(60*(1/4)*(3/4)) = sqrt(11.25) = approx 3.35. So to get 10 puts you less than 1.5 stdev from the mean. For normally distributed data (which I would expect the scores for such a test with random answer selection), 68% of the results are within 1 stdev, and 95% are within 2.
So, a score of 10 doesn't seem out of place at all. (And this is all high-school level stats, mind you, sticking to the Probability 101 theme here.)
There are some pieces of code at work where the "constantly switch off projects and tasks" has been applied almost as an anti-pattern. Glue scripts with code dating back 15 years, where probably a dozen or more different folks have gone in and made their "one little tweak", trying not to disturb the rest. We end up with a script with 50 flags, and who knows what subset of those flags is still relevant or really works.
Every so often, someone goes in there and removes some of the cruft, but it is still the result of dozen or more people hacking and slashing to "get something working." Half or more of the "comments" in the code are commented-out old versions of some code path that had been tweaked for the present need. Scar tissue abounds. Looking at the script now, I see one if-statement where all the code in the body of the if-statement is commented out, but the if itself isn't. Lovely! Tons of short blocks of code commented only with a cryptic test-case ID that triggered the need. (Note: These aren't test cases for the script, these are test cases the script loads into something else.)
And yet, the code continues to function. And it does get tested. The particular script I'm thinking of that's the most egregious offender sits at the heart of a verification flow: It launches the design under test.
Where I work, we've mined many products which failed to reach the market for good ideas. Often, there were many good ideas in there, it was just the package as a whole that didn't work out. (Either too early, too late, too big or too small.) But, we've also had good continuity among our key folks (myself included), so that probably explains why it ends up working. We understood why we put those features in failed product X, and so we understand how they'd work in new, more viable product Y. We also understand at least something about why X failed, so we can try to avoid it on Y.
But again, that does rely on institutional memory to make it work.
Well, like I said in my followup "reply to self", it really does depend on the nature of the task. We don't have enough information to go on. The TI DSP cards do fill an interesting niche, though, and are a nice counterpoint to the Tesla cards in many applications.
Really, you need to just get some demo tools for a couple platforms, do some benchmarks, and see how each platform feels. You'd be silly to drop $10,000 - $15,000 on a server without first running some benchmarks on a smaller version of what you intend to buy, as well as collecting some data on how the results on the small system scale to the proposed larger system.
Proposing a solution and working backwards only truly works for constructing those initial benchmarks.
I personally try to tackle a big new thing regularly. I started realizing I needed to do that around 5 years ago, right around when I hit the 10 year mark at work. Until then, I was largely a C/ASM programmer, with a lot of experience in that area, but not so much outside it. I realized I was in danger of becoming a one-trick pony, programming-wise. Since then, I've gained expertise in System C, Perl, Moose, C++, OO design patterns, compiler theory, etc. Currently I'm taking those free Stanford AI and ML courses, and teaching myself ARM assembly language. I'll probably tackle Python someday.
My job title isn't programmer at all, and I'm not even a software engineer. I'm a processor/SoC architect part of the time, a sort-of DV person part of the time (really, a cross-check on our DV), and a jack-of-all-trades the rest of the time. I do write a lot of software, either for analysis, or automation, or verification. (Hence all the Perl, automating the daily doldrums.) But, that software is all to support my other activities, such as performance analysis, DV, simulation, etc.
Really, in the end, I'm a problem solver. And I've made it my personal goal to be as good a problem solver as I can be, and that means boning up on a wide array of stuff, regularly. If someone asked me "What programming language do I need to learn to get a high paying job?" I'd say "Whatever people are paying money for today, and keep in mind the answer will be different tomorrow. Prepare to keep learning new languages and skills."
And you're right: The vast majority out there don't think like that at all. It's like pushing a wet noodle trying to get folks to learn new skills or better ways of doing things.[*] Or, they will begrudgingly learn it if someone hand-holds them through the whole process. Come ON people! Show some initiative! More than once I've been stymied by "Oh, we don't know how to do that, and so and so who does is too busy to look at it," only to break the deadlock by figuring out how to do it myself. (Often, it was surprisingly easy.)
That difference in attitude is why I think I won't have a problem for the next 15 years of my career. (I just hit the 15 year mark this year.) Some of my coworkers, not so much.
[*] Anecdote from a friend in another industry: She works in a group that handles documentation for a healthcare products company. She was telling me how her coworkers insert page breaks in their Word documents: Press "enter" enough times to get to a new page. And they refuse to do differently. "Insert Page Break" is "too much" for them. It's not just the programming industry. It's everywhere.
I should add also that depending on the nature of your task, it may perform closer or further from the "peak" performance on the DSP vs. on a GPU. So a single Tesla 1 TFLOP card may not perform the same as a single DSP 1 TFLOP card.
There's some high-powerd PCI cards filled with TI DSPs that you can get. Here's an article describing some of them. In terms of power efficiency per unit of work, the DSPs blow the doors off the main processor and the GPUs. Each DSP on the chip can do 16 single precision or 4 double precision floating point operations per cycle, at around 1GHz, and they're programmable in C/C++.
Relevant quote:
Buy 5 of these and you're only at 550W, $10,000 and 5 TFLOPs.
Who says they'd find out? All they'd know is that you used their software to open up a port. And, given that Conficker landed with a thud to begin with, perhaps the spooks had taken over its C&C infrastructure and was pretty certain it had control over it. If you can get someone else to do your dirty work without them realizing they're doing it, it's harder to trace back to you.
It also seems possible that whoever wrote Stuxnet had pulled apart one or more pre-existing worms out there and decided to commandeer one, or at least collect intelligence from it. I mean, if someone has already done a bunch of dirty work for you, and you can piggy back on it "safely", then you have an effective vector for fast initial deployment.
Well, it would allow for about a 10% sag in the AC source, if that was 440v. 90% of 440v is 396v, which gives you some margin for conversion losses.
The current carrying capacity of the wires would need to be about 30 times larger, though, to deliver the same amount of power. That's pretty huge. To go to 12v everywhere, you'd need huge current-carrying wires everywhere (think "as big as your car battery cables or bigger"). To carry 1kW through a 380V line, you only need to handle 2.6A. To carry 1kW through a 12v line, you need to handle 83A. And that's just one beefy server.
Now think of your house wiring. Outside of your major appliances, where do you see runs higher than 15A or maybe 30A? There's a reason high voltage is good.
The problem with DC back in Edison's day was that you couldn't easily step it up or down. DC doesn't have higher losses than AC at the same voltage. In fact, DC radiates less energy away than AC does, and is therefore more efficient.
Ohmic losses all come down to I^2 * R. R is the resistance of the cable, and I is current. To deliver a given amount of power, you have to have a certain V*I. To reduce Ohmic losses, then, you have to reduce the amount of current, which means going up in voltage.
Incidentally, that's also what's driving automobile manufacturers toward 48v instead of 12v, since it would cut the current from the battery by a factor of 4, thereby reducing the amount of loss in the wiring by a factor of 16. That means you can use smaller wires to deliver the same amount of power, safely.
It's a Pentium in as much as they named it "Pentium," much like a Ford Taurus of today is just as much a Ford Taurus as one they made 20 years ago, even though they have no parts in common. It's a Taurus because Ford named it that.
The Intel Atom probably has more in common with the original P54C than the Pentium Pro did.
Hmmm... processors do do more work per clock nowadays as compared to 12 years ago. And, they do it at waaaaaaaay less power and cost. Think about your huge many-fanned nearly 1kW rig from the turn of the millennium vs. the cramped space of a 1U slot pulling maybe 100W. This ain't your father's Pentium.
*shrug* Probably. My main point was that there's a ton of compute power lying between any two endpoints of an SMS, and that the magnitude of the problem (grepping for 1600 bad words) is very, very, very small compared to that, even if you absurdly overestimate the cost by several orders of magnitude.
Yeah, my point was mainly to demonstrate that even if you turn all the knobs to 11, it's still easily doable.
BTW, I realize this is Pakistan that we're talking about, not the US. I just used the US numbers to get an initial order of magnitude to get in the ball park for the number of SMSes/sec a given cell tower might see, on the presumption that a cell tower in the US has a similar amount of work to do per subscriber as a cell tower in Pakistan.
What, you think they're going to do this on a Commodore 64?
I looked it up, and folks in the US send 80 billion SMSes per month. That works out to about 30k SMSes/sec on average across the entire United States. Now, I realize that certain times of day are more likely to have SMSes than others, so let's say, to a first order, the peak rate of SMSes is 100k/sec. Now divide that among all the cell towers, understanding that some will be busier than others.
Let's say a given cell tower has to process 100 SMSes a second, each at the full 160 character limit. That's 16kB/s. Let's say each word take 1000 cycles to test for, which should be on the high side since it assumes you can't use, say, a trie to take advantage of common word roots, or use pattern matching accelerators (which are quite common in this space). 16kB/s * 1000 * 1600 = 25.6Gcyc/sec. That sounds like a lot, but it isn't.
A single board in one of these cellular base stations has literally dozens of processor chips, most with multiple cores, running in the GHz range. And that's just one board. My employer sells a chip in this space which crunches away 10Gcyc/sec across all of its 8 processors, and our customers put dozens of these on each board.
On GSM networks, SMSes are control channel messages. They go via a low bandwidth side channel that is nowhere near as compute-intensive as the main voice channel. If you're provisioned to handle a certain number of phone calls, you're more than adequately provisioned to handle SMSes and the corresponding filtering, as long as you do the filtering at the base station.
And Abe Lincoln.
Something tells me, though, it refers to reefer in this context.
What are you doing on it during that time? The processor, baseband and RF circuits also suck up a fair juice. That PDF I linked above shows GSM consuming around 600mW during GPRS and WiFi consuming around 700mW when in use on the phone they analyzed. I'd expect other phones to be similar. 3G is supposedly much worse at draining batteries. Dunno about CDMA/LTE, but I would imagine they'd also be in the half-watt to 1 watt range, to venture a first-order guess.
If you're just playing games, then it's just the CPU, RAM and display sopping the battery.
Yeah, I can see that. I guess "mobile device" doesn't just mean "mobile phone" these days.
Is the display really that much of a hog on a cell phone? Those numbers sound like laptop numbers, but I thought we were talking cell phones.
My phone has a battery that holds around 1300 mAh at 3.7v. That means I can draw 4.8W for 1 hour. If my phone's display really sucked down even 10W, then I wouldn't be able to have the display on for more than about 28 minutes total, which doesn't match my experience at all. I regularly browse the web from my phone for a half hour at a time, without making much of a dent in the battery.
A quick scan through this paper suggests backlight power for the phone they analyzed tops out at 414mW, and the LCD display power ranges from 33.1mW to 74.2mW. If you drop the brightness back just a few notches, the total display power is around a quarter Watt or so, which sounds far more reasonable.
I don't think Intel is standing still on power consumption. Their desktop CPUs are hogs, sure, but they can bring a lot of engineers to bear optimizing Atom-derived products. (We might get an early read from Knight's Corner, actually, although I expect it to still be on the "hot" side. I'm waiting to hear more about it.) Also, ARM's latest high-end offerings (including the recently announced A15) aren't exactly as power-frugal as some of their past devices. In the next couple years, I think the scatter plot of power vs. performance for ARM and x86 variants will show a definite overlap in the mix, with some x86s pulling less power than some ARMs.
Hey, don't knock my Diamond Stealth 64! It's got VLB!
Wow, does someone help you dress in the morning? You realize EAX is a sound technology, and Carmack's Reverse is a graphics technique, right?
But, where in all of that "non-specialization" did you learn about DNS records, whatever the hell Active Directory does, and TV trivia?
Consider TV shows: There are sci-fi geeks that are into Trek, geeks that are into Babylon 5, geeks that are into Doctor Who, geeks that are into Battlestar Galactica, geeks that are into Firefly, etc. If you draw a Venn diagram of all these, I think you'd find significant regions of non-overlap, which implies a certain amount of specialization. (Actually, I'm not sure you could draw the Venn diagram accurately on a planar surface unless you break up some of the bubbles.)
Are geeks required to limit themselves to late-70s/mid-80s circuitry and low level assembly programming to be considered geeks? That notion is absurd. There were geeks before TTL existed, and there are geeks today that were born after CPUs started their steady march from 3.3v down to sub-1v today, leaving behind old school TTL. Geekdom is a form of specialization, and there will always be subdomains within geekdom. That's what I mean by specialization.