50% increase - Only an idiot tells the truth!
on
Salary Histories
·
· Score: 1
And if you're not really worth that $120K, you'll be the first to be targeted when things go sour.
salary = experience + proven value
on
Salary Histories
·
· Score: 1
IMHO, engineering is 90% applied common sense and 10% specialized knowledge. CS classes are 90-100% specialized knowledge and 10% applied common sense.
That isn't to say that CS education's not useful. It is. It's partly because a big part of the applied common sense is knowing when and where to apply what specialized knowledge, and partly because well-designed courses can actually help in acquiring some of that common sense (project labs, for example).
One of my favorite undergraduate classes was structured more as a "humanities" class, in the sense that it had no lab component and no problem sets. Instead, it consisted of reading papers (some of which were key contributions to the field) and analyzing them in writing, in addition to two term papers that consisted of design work on a problem (note that I emphasize design work -- remember, there was absolutely no coding going on). The class was called "Computer Systems Engineering". Well, guess what -- having to analyze something, looking for its weak points, and writing cogently about it is excellent training in thinking and making decisions, which is what we're (almost) all paid to do. I loved the class, but it was not universally popular. I think some of the students considered anything not involving coding or heavy mathematics was beneath their dignity (translation: "I'm not very good at this.")
This was essentially a liberal arts course. I saw it that way (it was not officially a liberal arts course) because it emphasized open-ended thinking over regurgitation or mental gymnastics. The fact that the subject matter was engineering design rather than constitutional law or political science or traditional literature is irrelevant; it's the methodology that counts. And for that matter, I'm glad I did take constitutional law -- aside from being a nice change of pace from pressure-cooker problem sets, the vigorous debate in class helped me to learn to organize my thinking. And that matters in *any* field.
I'm probably not all that much better of a coder than I was 10 years ago, but I think I've honed my analytical skills by working on a variety of different projects with different people. I may not be as up to date on the latest of everything, but I'm well aware that I get asked to troubleshoot a very large fraction of the difficult, thorny problems, and I'm respected for that. Being able to consistently do something useful well is part of "proven value".
The downside is that not everyone wants to be alerted to a possible problem down the road. Sometimes it's seen as obstructionist. Sometimes I see something that troubles me, even though I don't consciously know why, and raising a red flag that's not blindingly obvious. Then again, remarkably often, it turns out in retrospect that I was right. Sometimes it turns out that I was wrong. That's life.
There's an excellent book published by Microsoft Press. Its author is Steve (not _Code Complete_, and I don't think it was Steve McConnell). It's targeted at project management. Unfortunately, its name escapes me. It's also rumored that Microsoft working practices don't really square with what's written in the book, but no matter. The book is very well worth reading by anyone in the engineering professions.
I doubt very much that anything but the most synthetic of benchmarks will get anything like the 12.5% gain implied by the clock speed. On the other hand, a 75% increase in CPU cost does not translate to a 75% increase in system cost, so the effects partially cancel each other out.
But it's really silly, anyhow; just get a Celeron 300A and clock it at 450, and you're probably within 10% of any of these puppies, unless you have an application that specifically takes advantage of the larger cache (i. e. blows the Celeron cache but fits in the K6-III cache). That saves another $200, so you can buy another Celeron or two in case the first one goes bad.
Of course, in a server context things are a bit different...but then again, most "servers" these days need I/O more than cycles.
Bullshit cuts both ways...
on
K6-3 on Monday
·
· Score: 1
It's always easy to come up with examples that prove one thing or another. When we're talking about matrix algebra and FFT's, it becomes easier yet.
The computational kernels for all of these algorithms are very easy to optimize for any given cache size and number of CPU's (and, for that matter, number of floating point units). If the code you used was optimized for 256K or 512K of cache and whatever cache algorithm the PII uses it doesn't surprise me that it runs badly on a Celeron A. 128K should be enough cache to get decent performance from a matrix multiply.
The FFT's an interesting case, since the radix 2 kernel only uses about 5 flops, so a lot of people use radix 4 and 8 kernels to reduce memory (or cache) traffic. Of course, the x86 FPU architecture gets in the way here; there simply aren't enough registers and the stack architecture's all wrong. Radix 8 and vectorized radix 2 and 4 kernels are an interesting exercise in register and pipeline management. Then there are the twiddles (nth roots of 1). So OK, I'll grant that the FFT is more cache intensive, but there are clever ways to tune it for different cache sizes.
In any event, I would not pick any x86 architecture for large FFT's. For more typical 1024 point FFT's, though, the Celeron has enough cache (128K is enough for about 8K complex points; divide that by 4 to allow for the twiddle factors and other cache busting stuff, and you're still at 2K). But again, the FPU architecture is all wrong.
Moral responsibility can be the strongest of all. Linus and RMS and Alan Cox and Larry Wall stake their personal reputations on the quality of their software, and know that if they let their standards slip they'll have to live with the opprobrium of their peers and their consciences. In a typical commercial setting there are a lot of competing interests -- this quarter's revenue, a promise to a key customer -- and this leads to lack of focus on product quality in some cases. Stockholders and VC's don't care if a product has a bug unless it's going to directly impact the bottom line.
As for the nuts and bolts, many of the best open source programmers work on those aspects. Alan Cox maintains vast swathes of the low levels of the Linux kernel, and owns responsibility for 2.0 maintenance (yes, 2.0.36 is quite recent, and 2.0.37 pre-patches are coming out periodically). Stephen Tweedie and Ingo Molnar do a lot of work on the VM system. Whatever their fame or lack thereof in the outside world, their peers are well aware of their accomplishments.
Sorry, but I don't buy that. Solaris and AIX have no problem with big files on 32-bit platforms. 32-bit platforms are normally limited to 32-bit address spaces (modulo games such as segments and some of the other truly horrible DOS and Windows hacks), but there's no compelling reason why file size and physical memory should be constrained by processor word length.
Libertarian venue??? People of all stripes are her
on
Why Work Sucks
·
· Score: 1
Since when has Slashdot ever advocated a political position? We even have people around here who like Microsoft:-!
Slashdot Mirror
And if you're not really worth that $120K, you'll be the first to be targeted when things go sour.
IMHO, engineering is 90% applied common sense and 10% specialized knowledge. CS classes are 90-100% specialized knowledge and 10% applied common sense.
That isn't to say that CS education's not useful. It is. It's partly because a big part of the applied common sense is knowing when and where to apply what specialized knowledge, and partly because well-designed courses can actually help in acquiring some of that common sense (project labs, for example).
One of my favorite undergraduate classes was structured more as a "humanities" class, in the sense that it had no lab component and no problem sets. Instead, it consisted of reading papers (some of which were key contributions to the field) and analyzing them in writing, in addition to two term papers that consisted of design work on a problem (note that I emphasize design work -- remember, there was absolutely no coding going on). The class was called "Computer Systems Engineering". Well, guess what -- having to analyze something, looking for its weak points, and writing cogently about it is excellent training in thinking and making decisions, which is what we're (almost) all paid to do. I loved the class, but it was not universally popular. I think some of the students considered anything not involving coding or heavy mathematics was beneath their dignity (translation: "I'm not very good at this.")
This was essentially a liberal arts course. I saw it that way (it was not officially a liberal arts course) because it emphasized open-ended thinking over regurgitation or mental gymnastics. The fact that the subject matter was engineering design rather than constitutional law or political science or traditional literature is irrelevant; it's the methodology that counts. And for that matter, I'm glad I did take constitutional law -- aside from being a nice change of pace from pressure-cooker problem sets, the vigorous debate in class helped me to learn to organize my thinking. And that matters in *any* field.
I'm probably not all that much better of a coder than I was 10 years ago, but I think I've honed my analytical skills by working on a variety of different projects with different people. I may not be as up to date on the latest of everything, but I'm well aware that I get asked to troubleshoot a very large fraction of the difficult, thorny problems, and I'm respected for that. Being able to consistently do something useful well is part of "proven value".
The downside is that not everyone wants to be alerted to a possible problem down the road. Sometimes it's seen as obstructionist. Sometimes I see something that troubles me, even though I don't consciously know why, and raising a red flag that's not blindingly obvious. Then again, remarkably often, it turns out in retrospect that I was right. Sometimes it turns out that I was wrong. That's life.
There's an excellent book published by Microsoft Press. Its author is Steve (not _Code Complete_, and I don't think it was Steve McConnell). It's targeted at project management. Unfortunately, its name escapes me. It's also rumored that Microsoft working practices don't really square with what's written in the book, but no matter. The book is very well worth reading by anyone in the engineering professions.
I doubt very much that anything but the most synthetic of benchmarks will get anything like the 12.5% gain implied by the clock speed. On the other hand, a 75% increase in CPU cost does not translate to a 75% increase in system cost, so the effects partially cancel each other out.
But it's really silly, anyhow; just get a Celeron 300A and clock it at 450, and you're probably within 10% of any of these puppies, unless you have an application that specifically takes advantage of the larger cache (i. e. blows the Celeron cache but fits in the K6-III cache). That saves another $200, so you can buy another Celeron or two in case the first one goes bad.
Of course, in a server context things are a bit different...but then again, most "servers" these days need I/O more than cycles.
It's always easy to come up with examples that prove one thing or another. When we're talking about matrix algebra and FFT's, it becomes easier yet.
The computational kernels for all of these algorithms are very easy to optimize for any given cache size and number of CPU's (and, for that matter, number of floating point units). If the code you used was optimized for 256K or 512K of cache and whatever cache algorithm the PII uses it doesn't surprise me that it runs badly on a Celeron A. 128K should be enough cache to get decent performance from a matrix multiply.
The FFT's an interesting case, since the radix 2 kernel only uses about 5 flops, so a lot of people use radix 4 and 8 kernels to reduce memory (or cache) traffic. Of course, the x86 FPU architecture gets in the way here; there simply aren't enough registers and the stack architecture's all wrong. Radix 8 and vectorized radix 2 and 4 kernels are an interesting exercise in register and pipeline management. Then there are the twiddles (nth roots of 1). So OK, I'll grant that the FFT is more cache intensive, but there are clever ways to tune it for different cache sizes.
In any event, I would not pick any x86 architecture for large FFT's. For more typical 1024 point FFT's, though, the Celeron has enough cache (128K is enough for about 8K complex points; divide that by 4 to allow for the twiddle factors and other cache busting stuff, and you're still at 2K). But again, the FPU architecture is all wrong.
As for the nuts and bolts, many of the best open source programmers work on those aspects. Alan Cox maintains vast swathes of the low levels of the Linux kernel, and owns responsibility for 2.0 maintenance (yes, 2.0.36 is quite recent, and 2.0.37 pre-patches are coming out periodically). Stephen Tweedie and Ingo Molnar do a lot of work on the VM system. Whatever their fame or lack thereof in the outside world, their peers are well aware of their accomplishments.
Sorry, but I don't buy that. Solaris and AIX have no problem with big files on 32-bit platforms. 32-bit platforms are normally limited to 32-bit address spaces (modulo games such as segments and some of the other truly horrible DOS and Windows hacks), but there's no compelling reason why file size and physical memory should be constrained by processor word length.
Since when has Slashdot ever advocated a political position? We even have people around here who like Microsoft :-!