Please explain to me what is it exactly you don't understand?
You've clearly written pay checks or submitted budgets.
What do you do think is the average cost per employee at your company?
If you make around $55K-$60K per year and work for an established company you are probably costing right around $100K per year. Does that make you an overpaid primadonna?
I think these efforts are great, maybe you can answer this for me.
"It will soon begin work on the 2,500 titles published by the Stanford University Press."
Aren't many of these (and others) already in some digital source format, at least those from the past 20 years say? Why would these need to be scanned at all?
Re:I'm sure you'll hear about this one..
on
SGI launches R16000
·
· Score: 1
Actually, good guess, I have worked on scientific visualization, simulation, manufacturing and content creation on both SGI and other platforms. That doesn't mean I'm a cheerleader or that I'm on some kind of "SGIHAD".
As far as I'm concerned there have always been three distinct reasons to buy desktop systems from SGI:
1. You need to develop an app and you want access to specialized development tools. Let's not forget they invented OpenGL and a few other useful apis.
2. You need to run an app that only runs or runs better on SGI because of special hardware or because the people who wrote it came to discover reason #1.
3. You want to develop or run an app that you want to scale to the mega multi-cpu systems we were discussing. You do realize that many O2 and Fuel workstations are sold to support the development or use of Onyx apps.
Price comparisons are only useful when comparing systems with equivalent specs. You always pay a premium for unique technology differentiators, partly to support the costs of the R&D that led to them and partly because the manufacturer can get away with it due to lack of competition. I believe this addresses your comments on both big iron and desktop systems.
Now I will in turn make the assumption that you are not in a position to be making real purchase decisions about high-end systems. This does not undermine fact that you are right about one thing: that they are less situations nowadays where the decision to buy SGI is a nobrainer since others have now caught up with them on many fronts. However, please do not presume that those of us who make these purchase decisions, do so because the spinning SGI logo is cool.
I will admit that once in a great while I get nostalgic for the good old days when SGI was Silicon Graphics and groovy was groovy. But then I remember how much 256MB of RAM and a decent graphics card used to cost.
Re:I'm sure you'll hear about this one..
on
SGI launches R16000
·
· Score: 1
I'm not as annoyed at your ill-informed comments as I am with the person who tagged them as insightful. When exactly did insightful become a synonym for retarded?
As for the content of your post, none of the chips you mention as replacements for SGI's cpu allow for any meaningful single image multi-cpu scaling. It wouldn't matter if a P4 was indeed twice or thrice as fast as an R16000 if someone's application requires 128 cpus to work on the same data in a single computer (not a cluster); since P4 based (or your other examples) architectures do not scale beyond two or four cpus. You don't have to be mesmerized to realize that, it's just a fact.
Somehow I don't think you actually care about the facts and you were trolling. If you were, congratulations and consider this a late xmas gift.
I think you're a bit scattered in your argument here. Be careful in quoting Christensen without actually clearly identifying the substaining and the disruptive technology and carrying out the logic to understand the value networks.
Seems to me that IBM's top tier supercomputer customers do not actually need this the most. They have their big iron and they keep it occupied 24/7/365. If they were, then this would indeed be a substaining technology and they would care what Joe PC thinks. They wouldn't calling this a paradigm shift, they'd be meeting individually with Wal-Mart, Amex etc to show them their new "customer driven" value proposition.
I think they are actually trying to disrupt the high-end PC / Workstation corporate power user market. Why should you buy a $50K quad-cpu system that can run your FEA sim in 16 hours, when you could send the app and data to IBM, pay $500 and get it done in 30min? Especially if the nature of your work means that you would actually like to run 7 different ones on a given day but only once every two weeks.
The distributed model argument is also incomplete since obviously some apps do not lend themselves to it. If you have an engineering app that needs 64bit floating point precision and 4Gigs of (single image) RAM, you can't always just send it to the secretaries' PCs to run overnight as a screensaver. You can however upload it to IBM and they'll have system config that will meet your needs.
I don't think so, there are many ways to test or approve without actually having to run it on the target much less seeing the source code. It's much easier to run it on a emulator or smaller binary compatible system. They won't waste engineering time trying to understand your code.
What nasty things are you referring to anyhow? Tie up the cpu or other ressources, that's what you're paying for! You don't actually think you'll be able to crash the system or damage the OS or commandeer the hardware somehow? Even if you could, your user contract would make you liable for the costs.
You'll have an account directory on some system where your binary and permanent files will reside. When you login, you'll upload your job submission and required data, then you'll be on a job queue with a priority rating and cpu/ram/disk quota. They won't even know themselves which actual machine you'll be running on until the scheduler decides. When the job's done you'll be notified or directly sent the output files. The only person who'll care about your source code is you because if it's poorly written it will mean IBM will send you a bigger "utility" bill.
Wouldn't it more useful and accurate to compare it to compare it to Intel's 64bit Itanium 2?
I guess most of us are more familiar with the P4 but for someone try to choose a platform for a future 64bit app, the choice will be I2, G5 or Hammer. To a great extent, how these compare to their 32bit cousins will be moote if your app actually has 64bit precision or memory requirements.
Please correct if I'm wrong, but the main problem with NR is that the routines were optimized for computers where the computational cost of a multiplication was many times that of an addition or a memory fetch. Now, in most modern fpus, multiplications are single cycle operations. Therefore the optimization strategy of replacing a mult with several adds and fetch which contributed to the "terrible coding style" is not only now unnecessary it actually ends up slowing down the code. It also makes it less transparent to compiler level optmizations so that it can't benefit from pipelining, branch prediction and out-of-order execution features. They would need to be rewritten from the original algorithms taking in account the present day actual computational cost of add, move, mult and the higher order functions of sqrt, exp... for that matter. They would turn out to be more legible and intuitive for both programmers and compilers.
Slashdot Mirror
You've clearly written pay checks or submitted budgets.
What do you do think is the average cost per employee at your company?
If you make around $55K-$60K per year and work for an established company you are probably costing right around $100K per year. Does that make you an overpaid primadonna?
Is this trimming the fat 10% across the board?
or
Does this mean some departments (read product lines) are to be put down?
"It will soon begin work on the 2,500 titles published by the Stanford University Press."
Aren't many of these (and others) already in some digital source format, at least those from the past 20 years say? Why would these need to be scanned at all?
Actually, good guess, I have worked on scientific visualization, simulation, manufacturing and content creation on both SGI and other platforms. That doesn't mean I'm a cheerleader or that I'm on some kind of "SGIHAD".
As far as I'm concerned there have always been three distinct reasons to buy desktop systems from SGI:
1. You need to develop an app and you want access to specialized development tools. Let's not forget they invented OpenGL and a few other useful apis.
2. You need to run an app that only runs or runs better on SGI because of special hardware or because the people who wrote it came to discover reason #1.
3. You want to develop or run an app that you want to scale to the mega multi-cpu systems we were discussing. You do realize that many O2 and Fuel workstations are sold to support the development or use of Onyx apps.
Price comparisons are only useful when comparing systems with equivalent specs. You always pay a premium for unique technology differentiators, partly to support the costs of the R&D that led to them and partly because the manufacturer can get away with it due to lack of competition. I believe this addresses your comments on both big iron and desktop systems.
Now I will in turn make the assumption that you are not in a position to be making real purchase decisions about high-end systems. This does not undermine fact that you are right about one thing: that they are less situations nowadays where the decision to buy SGI is a nobrainer since others have now caught up with them on many fronts. However, please do not presume that those of us who make these purchase decisions, do so because the spinning SGI logo is cool.
I will admit that once in a great while I get nostalgic for the good old days when SGI was Silicon Graphics and groovy was groovy. But then I remember how much 256MB of RAM and a decent graphics card used to cost.
I'm not as annoyed at your ill-informed comments as I am with the person who tagged them as insightful. When exactly did insightful become a synonym for retarded?
As for the content of your post, none of the chips you mention as replacements for SGI's cpu allow for any meaningful single image multi-cpu scaling. It wouldn't matter if a P4 was indeed twice or thrice as fast as an R16000 if someone's application requires 128 cpus to work on the same data in a single computer (not a cluster); since P4 based (or your other examples) architectures do not scale beyond two or four cpus. You don't have to be mesmerized to realize that, it's just a fact.
Somehow I don't think you actually care about the facts and you were trolling. If you were, congratulations and consider this a late xmas gift.
I think you're a bit scattered in your argument here. Be careful in quoting Christensen without actually clearly identifying the substaining and the disruptive technology and carrying out the logic to understand the value networks.
Seems to me that IBM's top tier supercomputer customers do not actually need this the most. They have their big iron and they keep it occupied 24/7/365. If they were, then this would indeed be a substaining technology and they would care what Joe PC thinks. They wouldn't calling this a paradigm shift, they'd be meeting individually with Wal-Mart, Amex etc to show them their new "customer driven" value proposition.
I think they are actually trying to disrupt the high-end PC / Workstation corporate power user market. Why should you buy a $50K quad-cpu system that can run your FEA sim in 16 hours, when you could send the app and data to IBM, pay $500 and get it done in 30min? Especially if the nature of your work means that you would actually like to run 7 different ones on a given day but only once every two weeks.
The distributed model argument is also incomplete since obviously some apps do not lend themselves to it. If you have an engineering app that needs 64bit floating point precision and 4Gigs of (single image) RAM, you can't always just send it to the secretaries' PCs to run overnight as a screensaver. You can however upload it to IBM and they'll have system config that will meet your needs.
I don't think so, there are many ways to test or approve without actually having to run it on the target much less seeing the source code. It's much easier to run it on a emulator or smaller binary compatible system. They won't waste engineering time trying to understand your code.
What nasty things are you referring to anyhow? Tie up the cpu or other ressources, that's what you're paying for! You don't actually think you'll be able to crash the system or damage the OS or commandeer the hardware somehow? Even if you could, your user contract would make you liable for the costs.
You'll have an account directory on some system where your binary and permanent files will reside. When you login, you'll upload your job submission and required data, then you'll be on a job queue with a priority rating and cpu/ram/disk quota. They won't even know themselves which actual machine you'll be running on until the scheduler decides. When the job's done you'll be notified or directly sent the output files. The only person who'll care about your source code is you because if it's poorly written it will mean IBM will send you a bigger "utility" bill.
Why compare it with the Pentium 4 at all?
Wouldn't it more useful and accurate to compare it to compare it to Intel's 64bit Itanium 2?
I guess most of us are more familiar with the P4 but for someone try to choose a platform for a future 64bit app, the choice will be I2, G5 or Hammer. To a great extent, how these compare to their 32bit cousins will be moote if your app actually has 64bit precision or memory requirements.
Please correct if I'm wrong, but the main problem with NR is that the routines were optimized for computers where the computational cost of a multiplication was many times that of an addition or a memory fetch. Now, in most modern fpus, multiplications are single cycle operations. Therefore the optimization strategy of replacing a mult with several adds and fetch which contributed to the "terrible coding style" is not only now unnecessary it actually ends up slowing down the
code. It also makes it less transparent to compiler level optmizations so that it can't benefit from pipelining, branch prediction and out-of-order execution features. They would need to be rewritten from the original algorithms taking in account the present day actual computational cost of add, move, mult and the
higher order functions of sqrt, exp... for that
matter. They would turn out to be more legible and intuitive for both programmers and compilers.