I'm going to partly retract what I sad above now that I've read more. While Programming Language Pragmatics may cover more ground, a lot of it is just trivial mention. This book sticks to the core of illustrating the concepts of modern programing, and fully exploring their possibilities. It's a different kind of book, and doesn't address the implimenters view as other "programing languages" books do. So far I'm really enjoying it.
all depends what those 1000 pages are full of. If it's 1000 pages of "teach yourself NEW_FAD_TECHNOLOGY in 21 days" then I'd agree. If it's 1000 pages of authoritative, carefully considered and exhaustive thought, then I'd say 1000 pages is to little... I'd like a lifetime supply.
As for this book... so far I've only skimmed, and for being free on the web as a preprint, I'd say it's fantastic. I'm also reading Programing Language Pragamtics right now, and it's a little more complete treatment of the same subject area.
Actually you need more than ethanol to cataylize the reaction, and you produce some byproduct, but most of it is useful.
But, while it sounds good in a vegitable patch in my back yard and drive 100 miles a year scale, it doesn't work at the national scale. Besides the staggering cost per gallon, growing grains that that scale would have enormous environmental damage. You just can't meet current US fuel demands with it. You'd need demand to fall by several orders of magnitude.
It's very true. If we want to stop air polution today, the only option that meets it is nuclear. Use nuclear to make hydrogen, or just put the power into the grid so people can charge pure electric cars. Either way, it's the only option we know of at the moment. We'd save the air at the price of irreversible damage to a few square miles of nevada where we burry the spent fuel and waste.
That's why most of the world has gone heavily nuclear, but the US still lags behind due to political issues. But even if we did go big nuclear and use hydrogen as the energy distrobution, it's still just another stopgap solution.
If you want to make a big Apollo style goal, going for the hydrogen economy is shooting behind the duck. It would save us from foreign oil, but we'd still be dependant on fossil fuel or more realisticly, nuclear power.
If you want to spend $100billion of *our* money, let's make it the goal of clean, sustainable energy without danger. The hydrogen economy is not this.
I've read a bit more of the original discussion instead of the stuff on the commercial site. It's not as bad as I suspected.
>Prevayler does the proper paranoid thing, syncing after every write.
What I've read does mention sync, but doesn't specify if it's strictly every command or if writes are combined.
>Prevayler applies commands in strict linear order.
I understand that now. Before I was assuming that there must be concurrency for performance, but once it sunk in how fast native object updates could be, strict synchronis execution doesn't seem all that limiting.
>I think the only remaining one is long transactions.
Indeed, this is the key assumption. If you can live with this, the database size requirements and give up ad hoc queries, then it seems very attractive.
I'm glad it's not as bad as I feared; I wish the promotional material was more clear on the technical details instead of being "why are you still using a database".
>Why don't you do some timings and put it up on their Wiki?
Because I don't care to. I just waiting to bring to light that for some systems, recovery time can be a very important part of downtime.
>The commands are logged before execution. If the server dies, you load the last snapshot and replay the log. What other assurance would you like?
Anyone who's worked with databases knows that assurance is not a bolean value.
How much does the software trust the underlying OS and hardware? For example, the fullest assurance possible would be to use blocking writes and fsync() after every command, and delay sending acknowledgement to the client until fsync completes. The most optimistic would be to immediately acknowledge to client, use non-blocking writes, and never bother to fsync.
Obviously these choices have dramatic impact on performance. I personally like that PostgreSQL lets you chose your level of safty on many issues like this.
There are some other details that I'd not pointed out before: transactions: Prevayler's concept of a transaction is a single large atomic command. What if your command is slow? Safe would be to serialize all commands, but I doubt that's what they do based on the performance. It appears they just don't acknowledge the issue. This means that the log written to disk might generate different final snapshots depending on the relative execution time between two different reconstructions.
In other words, non-determinism. Bad.
Next up is Rollback. That's just kindof braindead. There certainly *are* systems that don't need rollback, but the moment you need your system to participate in some larger integrated transaction, then you gotta have rollback.
Thier advice on this point is: just ensure your action is consistant *before* executing your command. So each command must check preconditions before executing. What about a real system where my preconditions are very long? In threaded code? I have to serialize things in my application now?
And it just gets worse from there. I'm not saying it's not useful, just again, that it solves a restricted set of problems compared to a general purpose dbms.
So Prevayler would be very fast for simple systems, like adding, reading and writing collections of simple values where I don't need to worry about isolation or consistancy (ie, their Scalability Test). But, I stronly suspect that when it would come to writing a system of any real complexity, you will either: 1.) have great performance, simple code, and no assurance against any of a number of possible problems. 2.) will code defensively against all these possible problems, and the resulting whole system will have signifigantly reduced performance.
It probibly won't get as slow as a traditional sql database, but I'd tend to think it would get at least as slow as any of the other java object databases.
So again, use the right tool for the job, and don't buy into their ~"you won't ever need a dbms again"~ marketing hype.
Well, his post is inflamitory but that doesn't mean he's wrong.
By holding everything in RAM you gain incredible speed, but have a firm limit on performance once your database exhausts available physical memory and starts paging. Then, the next limit is when you exhaust address space on 32bit machines, where you get a hard limit and no more allocations can take place.
Notice that they don't appear to mention recovery time, or the size of the changelog. They also don't mention the level of assurance.
There are main memory sql databases as well, and they also exhibit query performance far faster than traditional databases. They have the same limitations on physical ram and address space size as well.
There's multiple axes of scalability. Traditional databases do "ok" at latency, concurency, reliability and datasize scaling. Main memory databases do well at latency and concurrency at the price of the other two.
It looks well implimented, and is likely a good solution to many problems. Saying "this kicks Oracle's butt" is a distortion though: it solves different problems than traditional databases.
See my earlier post for why laptops might be running mssql.
It's true that a wire level virus scanner would have to be 'encoding aware'. We would never want to assume that a packet sniffer would eliminate all possible infections on our network.
But let's think about what it *could* do.
Well, the most common infection vector is email attachments. Since there's only a couple encodings, and your mail server likely only accepts on a couple ports, you could scan at the packet level. Most likely a checker on the mail server itself would be better.
What's the 2nd most common infection vector? downloaded.exe's and the like. Again, a packet level sniffer is only of limited use here, and it will be harder to deal with all possible ports, encodings and protocols. But, you could sill get reasonable results by say, scanning anything on an inbound http response that is encoded in a format you recognize.
What does that leave: well, probibly the most important infection vector for us to deal with at the packet level: worms that use various exploits in daemons and protocols. And here, a packet level sniffer can be extremely effective. Things like code red, sql slammer, etc are very easily recognized at the protocol level. Even better is for us to plug our box in upstream at our circut providers so that we can save our pipes from being clogged with infection packets. And with some sort of administration functions, we could use them to block some forms of DoS as well.
What's the point: with security, don't trust a single fence: build several to overlapp eachother, and a packet level sniffer could be a valuable tool in this context.
Sales guys may use a SFA solution that uses the MS data engine (ie, "diet" mssql) installed locally on their laptop for persistance. Sales guys also may hit the hibernate button instead of a full powerdown and powerup.
Therefor, it is possible that a business user plugging in his laptopt could release slammer.
When thinking about security, do not think "ohh, that can't happen, that's so unlikely". Think "what could make that possible, no matter how remote" and then "how can I eliminate that risk".
People have a lot of dogma, so I'll start off by saying both are worthwhile options and useful in situations that warrent them: right tool for right job.
In my experience the biggest difference has been with scalability. MySQL is typically faster if you have very few simultainious connections (ie, 4 or less). Unlike what some people say, MySQL seems to handle complex queries just fine unless you happen to hit the odd poorly optimized query.
But, if you're going to have a system with more connections, in my experience, Postgre scales MUCH better. It maintains pretty even throughput and latency at past 100 connections in what I've tested. MySQL fell flat when I did the same tests on it, but that was a while ago, things may be better now. When I looked, the big reasons for this seemed to be Postgre's more sophisticated locking and heavy use of shared memory for caches, etc.
Postgre's sore spot is replication.
I also think people are naievly obcessed with speed, or optimize the wrong way. I'm tired of seeing web apps that do 10 redundant queries over and over and never cache the results. Even if you're leaning on the database do cache and use persistant connections, that's a whole lot of memory copying that need not happen. The people that write this crap are typically the ones that are "Postgre is to slow".
Yeah, anything's slow if you code lame:/. I've never had a problem with Posgre's speed on any project.
This is kindof like the garbage collection vs free debate in programming languages.
The work vaccum does has to happen sometime. One choice might be to provide a mode that gives you 24/7 average case performance by always compacting when it can.
Or, you could go the deterministic route and chose when you pay that overhead, letting you schedual the best case performance.
I'm a fan of the latter, but think that the former should be available as well for people who can't schedual maintanence jobs durring downtime or take a mirror offline and back on.
There's a couple good articles on the web concerning Nasa's software development process. All in all, very similar to SigmaSix, with lots of statistical self-evaluation.
The bottom line is that this sort of method does work, and can lead to impressive software reliability. But, it also raises the cost per line of code by an order of magnitude or more.
I'm aware of functional programing, but they often include SP primatives as well. For example, Haskell is declaritive not because the constructs are different, but because of lazy evaluation. Most declaritive languages still carry many of the SP concepts forward.
But imagining a widespread general purpose langauge that does not have repetition, alternation or predication is a little more difficult. I suppose SQL qualifies as do various markup languages. Assembly does as well of course (after all, it's what motivated SP:P).
I understand about learning by demonstration, but you seem to have exhausted those options. So maybe learning by doing would not be ideal, but better than the instruction that is available.
I know there's a simulator for the CCNA. As for solaris, you could always get solaris x86, buy an old sun off ebay, or pick up the (relatively) cheap blade 100 to get some hands on.
The only individual training company I've heard good things about was DevelopMentor. Unfortunately they focus on software development, not administration or networking.
Definately Dijkstra... structured programming is probibly the single most widespread and powerful idea in the last 30 years of software.
Maybe OOP or something else will reach the same level of usage over the next thirty years, but it's hard to imagine what form any language could take without the basic repettitive constructs.
And certainly there were more people involved in SP than just Dijkstra, but then again Dijkstra contributed a staggering amount more than just SP as well.
the spec numbers released by AMD are "estimated" and used the intel compiler without the native x86 mode. they're all over the web:
hammer:
specint 1202
specfpu 1170
itanium2 numbers are real spec results available on their site:
specint 674
specfpu 1431
AMD says they expect hammer aware compilers to render a 20% performance improvement in fpu, thanks to using the extra registers, etc. This is likely true, but also convenient that it's just enough to bring them to the same level as I2.
In the end, hammer will always dominate i2 in performance per $ just based on the volumes of markets. As time progresses, itanium will ride moore's law wider, whereas it's not clear how hammer will capitalize on die shrinks. Interconnect delay is becoming the dominate issue, and so riding the clock advance like processor makers have been for the last 5 years will not be so straightforward.
I'm earger to by a hammer as well. Don't think I'm somehow badmouthing the chip. Just wanted to balance out over-enthusiastic statements like "it's the fastest thing ever!!!".
Yeah, I'd tend to agree. But, those of us with a couple classes or a couple good books under our belt are different than people who'd like a better understanding, but don't want it enough to go read a couple hundred pages of hennesy and patterson or whoever.
great enthusiasm, but a little mis-informed. As far as spec2k results go, Itanium2 is faster in floating point. And in the real world, "fastest" can vary by individual application, or even the particular inputs you give those applications.
leave it to slashdot to say how stupid something is without bothering to try and understand it.
to the end user, these phones are the same as any other. in this case, optical refers to where the multiplexing is happening: in the media instead of in dsp. it does not mean cell phones using lasers or visible spectrum to transmit data.
Sun is on the wrong end of an economic trend. If they don't re-invent themselves, they'll become trapped in a slowly dieing (heh) nitch.
The fact is, for the enterprise tasks most people would buy sun, these days the tasks parellelize well enough to run them on a cluster of commodity pc hardware. It isn't as reliable, but when you can afford a staggeringly larger number of resources, redundancy becomes very cheap.
Much like vector supercomputers became impactical for most workloads, replaced by beowulf style clusters, sun' hardware will be relegated to areas where massively parellel shared memory architectures are key. The final nail in sun's coffin will be when an x86 chip can address large memories.
perhaps. I personally think it's more likely that nvidia sees the cg software as a complement to commoditize, and as a way to get a home turf advantage. nVidia's focus has been pretty narrow (ie, going vertical being a mistake, etc) so I doubt they'd want to get into the software business.
Indeed, as an IHV, you can add whatever extension to the API you fancy, and software developers are given the option of using it. It is a little frustrating in that you, as a software developer, can't depend on the feature being there, but in practice it works well. For example, ATI and nVidia often update to transparently support eachothers extensions.
Periodicly, the ARB goes through and blesses some extensions, making them official. They're still optional in terms of compliance to the standard, but the ARB blessing catalizes a commonly supported API for each feature.
Eventually a new version of the spec is rolled, and usually the majority of changes were already seen as ARB extensions before.
So, OpenGL has managed a steady evolution. Where it has been slower in reguards to directx is in iterations of revolution. In five years DX went from being bizarre to being very similar to OpenGL, changeing the fundamental philosophy of the API design in the process. Dictatorships allow rapid broad changes like this. OpenGL has not done that so well, which is what the OpenGL 2.0 initiative is a response to.
Slashdot Mirror
I'm going to partly retract what I sad above now that I've read more. While Programming Language Pragmatics may cover more ground, a lot of it is just trivial mention. This book sticks to the core of illustrating the concepts of modern programing, and fully exploring their possibilities. It's a different kind of book, and doesn't address the implimenters view as other "programing languages" books do. So far I'm really enjoying it.
all depends what those 1000 pages are full of. If it's 1000 pages of "teach yourself NEW_FAD_TECHNOLOGY in 21 days" then I'd agree. If it's 1000 pages of authoritative, carefully considered and exhaustive thought, then I'd say 1000 pages is to little... I'd like a lifetime supply.
As for this book... so far I've only skimmed, and for being free on the web as a preprint, I'd say it's fantastic. I'm also reading Programing Language Pragamtics right now, and it's a little more complete treatment of the same subject area.
Actually you need more than ethanol to cataylize the reaction, and you produce some byproduct, but most of it is useful.
But, while it sounds good in a vegitable patch in my back yard and drive 100 miles a year scale, it doesn't work at the national scale. Besides the staggering cost per gallon, growing grains that that scale would have enormous environmental damage. You just can't meet current US fuel demands with it. You'd need demand to fall by several orders of magnitude.
It doesn't work that way. It ends up taking more energy to make hydrogen than the hydrogen can produce for you in a fuel cell or engine.
As a generalization: whenever you convert energy from one form to another, you lose some.
It's very true. If we want to stop air polution today, the only option that meets it is nuclear. Use nuclear to make hydrogen, or just put the power into the grid so people can charge pure electric cars. Either way, it's the only option we know of at the moment. We'd save the air at the price of irreversible damage to a few square miles of nevada where we burry the spent fuel and waste.
That's why most of the world has gone heavily nuclear, but the US still lags behind due to political issues. But even if we did go big nuclear and use hydrogen as the energy distrobution, it's still just another stopgap solution.
If you want to make a big Apollo style goal, going for the hydrogen economy is shooting behind the duck. It would save us from foreign oil, but we'd still be dependant on fossil fuel or more realisticly, nuclear power.
If you want to spend $100billion of *our* money, let's make it the goal of clean, sustainable energy without danger. The hydrogen economy is not this.
I've read a bit more of the original discussion instead of the stuff on the commercial site. It's not as bad as I suspected.
>Prevayler does the proper paranoid thing, syncing after every write.
What I've read does mention sync, but doesn't specify if it's strictly every command or if writes are combined.
>Prevayler applies commands in strict linear order.
I understand that now. Before I was assuming that there must be concurrency for performance, but once it sunk in how fast native object updates could be, strict synchronis execution doesn't seem all that limiting.
>I think the only remaining one is long transactions.
Indeed, this is the key assumption. If you can live with this, the database size requirements and give up ad hoc queries, then it seems very attractive.
I'm glad it's not as bad as I feared; I wish the promotional material was more clear on the technical details instead of being "why are you still using a database".
>Why don't you do some timings and put it up on their Wiki?
Because I don't care to. I just waiting to bring to light that for some systems, recovery time can be a very important part of downtime.
>The commands are logged before execution. If the server dies, you load the last snapshot and replay the log. What other assurance would you like?
Anyone who's worked with databases knows that assurance is not a bolean value.
How much does the software trust the underlying OS and hardware? For example, the fullest assurance possible would be to use blocking writes and fsync() after every command, and delay sending acknowledgement to the client until fsync completes. The most optimistic would be to immediately acknowledge to client, use non-blocking writes, and never bother to fsync.
Obviously these choices have dramatic impact on performance. I personally like that PostgreSQL lets you chose your level of safty on many issues like this.
There are some other details that I'd not pointed out before: transactions: Prevayler's concept of a transaction is a single large atomic command. What if your command is slow? Safe would be to serialize all commands, but I doubt that's what they do based on the performance. It appears they just don't acknowledge the issue. This means that the log written to disk might generate different final snapshots depending on the relative execution time between two different reconstructions.
In other words, non-determinism. Bad.
Next up is Rollback. That's just kindof braindead. There certainly *are* systems that don't need rollback, but the moment you need your system to participate in some larger integrated transaction, then you gotta have rollback.
Thier advice on this point is: just ensure your action is consistant *before* executing your command. So each command must check preconditions before executing. What about a real system where my preconditions are very long? In threaded code? I have to serialize things in my application now?
And it just gets worse from there. I'm not saying it's not useful, just again, that it solves a restricted set of problems compared to a general purpose dbms.
So Prevayler would be very fast for simple systems, like adding, reading and writing collections of simple values where I don't need to worry about isolation or consistancy (ie, their Scalability Test). But, I stronly suspect that when it would come to writing a system of any real complexity, you will either:
1.) have great performance, simple code, and no assurance against any of a number of possible problems.
2.) will code defensively against all these possible problems, and the resulting whole system will have signifigantly reduced performance.
It probibly won't get as slow as a traditional sql database, but I'd tend to think it would get at least as slow as any of the other java object databases.
So again, use the right tool for the job, and don't buy into their ~"you won't ever need a dbms again"~ marketing hype.
Well, his post is inflamitory but that doesn't mean he's wrong.
By holding everything in RAM you gain incredible speed, but have a firm limit on performance once your database exhausts available physical memory and starts paging. Then, the next limit is when you exhaust address space on 32bit machines, where you get a hard limit and no more allocations can take place.
Notice that they don't appear to mention recovery time, or the size of the changelog. They also don't mention the level of assurance.
There are main memory sql databases as well, and they also exhibit query performance far faster than traditional databases. They have the same limitations on physical ram and address space size as well.
There's multiple axes of scalability. Traditional databases do "ok" at latency, concurency, reliability and datasize scaling. Main memory databases do well at latency and concurrency at the price of the other two.
It looks well implimented, and is likely a good solution to many problems. Saying "this kicks Oracle's butt" is a distortion though: it solves different problems than traditional databases.
Use the right tool for the job.
See my earlier post for why laptops might be running mssql.
.exe's and the like. Again, a packet level sniffer is only of limited use here, and it will be harder to deal with all possible ports, encodings and protocols. But, you could sill get reasonable results by say, scanning anything on an inbound http response that is encoded in a format you recognize.
It's true that a wire level virus scanner would have to be 'encoding aware'. We would never want to assume that a packet sniffer would eliminate all possible infections on our network.
But let's think about what it *could* do.
Well, the most common infection vector is email attachments. Since there's only a couple encodings, and your mail server likely only accepts on a couple ports, you could scan at the packet level. Most likely a checker on the mail server itself would be better.
What's the 2nd most common infection vector? downloaded
What does that leave: well, probibly the most important infection vector for us to deal with at the packet level: worms that use various exploits in daemons and protocols. And here, a packet level sniffer can be extremely effective. Things like code red, sql slammer, etc are very easily recognized at the protocol level. Even better is for us to plug our box in upstream at our circut providers so that we can save our pipes from being clogged with infection packets. And with some sort of administration functions, we could use them to block some forms of DoS as well.
What's the point: with security, don't trust a single fence: build several to overlapp eachother, and a packet level sniffer could be a valuable tool in this context.
Sales guys may use a SFA solution that uses the MS data engine (ie, "diet" mssql) installed locally on their laptop for persistance. Sales guys also may hit the hibernate button instead of a full powerdown and powerup.
Therefor, it is possible that a business user plugging in his laptopt could release slammer.
When thinking about security, do not think "ohh, that can't happen, that's so unlikely". Think "what could make that possible, no matter how remote" and then "how can I eliminate that risk".
People have a lot of dogma, so I'll start off by saying both are worthwhile options and useful in situations that warrent them: right tool for right job.
:/. I've never had a problem with Posgre's speed on any project.
In my experience the biggest difference has been with scalability. MySQL is typically faster if you have very few simultainious connections (ie, 4 or less). Unlike what some people say, MySQL seems to handle complex queries just fine unless you happen to hit the odd poorly optimized query.
But, if you're going to have a system with more connections, in my experience, Postgre scales MUCH better. It maintains pretty even throughput and latency at past 100 connections in what I've tested. MySQL fell flat when I did the same tests on it, but that was a while ago, things may be better now. When I looked, the big reasons for this seemed to be Postgre's more sophisticated locking and heavy use of shared memory for caches, etc.
Postgre's sore spot is replication.
I also think people are naievly obcessed with speed, or optimize the wrong way. I'm tired of seeing web apps that do 10 redundant queries over and over and never cache the results. Even if you're leaning on the database do cache and use persistant connections, that's a whole lot of memory copying that need not happen. The people that write this crap are typically the ones that are "Postgre is to slow".
Yeah, anything's slow if you code lame
This is kindof like the garbage collection vs free debate in programming languages.
The work vaccum does has to happen sometime. One choice might be to provide a mode that gives you 24/7 average case performance by always compacting when it can.
Or, you could go the deterministic route and chose when you pay that overhead, letting you schedual the best case performance.
I'm a fan of the latter, but think that the former should be available as well for people who can't schedual maintanence jobs durring downtime or take a mirror offline and back on.
There's a couple good articles on the web concerning Nasa's software development process. All in all, very similar to SigmaSix, with lots of statistical self-evaluation.
The bottom line is that this sort of method does work, and can lead to impressive software reliability. But, it also raises the cost per line of code by an order of magnitude or more.
I'm aware of functional programing, but they often include SP primatives as well. For example, Haskell is declaritive not because the constructs are different, but because of lazy evaluation. Most declaritive languages still carry many of the SP concepts forward.
:P).
But imagining a widespread general purpose langauge that does not have repetition, alternation or predication is a little more difficult. I suppose SQL qualifies as do various markup languages. Assembly does as well of course (after all, it's what motivated SP
I understand about learning by demonstration, but you seem to have exhausted those options. So maybe learning by doing would not be ideal, but better than the instruction that is available.
I know there's a simulator for the CCNA. As for solaris, you could always get solaris x86, buy an old sun off ebay, or pick up the (relatively) cheap blade 100 to get some hands on.
The only individual training company I've heard good things about was DevelopMentor. Unfortunately they focus on software development, not administration or networking.
that's awsome...
where's good info on the possible features of C++0x? I've seen the a/v presentations on technet from a year or so ago.
Definately Dijkstra... structured programming is probibly the single most widespread and powerful idea in the last 30 years of software.
Maybe OOP or something else will reach the same level of usage over the next thirty years, but it's hard to imagine what form any language could take without the basic repettitive constructs.
And certainly there were more people involved in SP than just Dijkstra, but then again Dijkstra contributed a staggering amount more than just SP as well.
yeah, all I gotta say is if he wants to live in the midwest, thank god it means he won't come up here to the northwest and increase my competition :P.
the spec numbers released by AMD are "estimated" and used the intel compiler without the native x86 mode. they're all over the web:
hammer:
specint 1202
specfpu 1170
itanium2 numbers are real spec results available on their site:
specint 674
specfpu 1431
AMD says they expect hammer aware compilers to render a 20% performance improvement in fpu, thanks to using the extra registers, etc. This is likely true, but also convenient that it's just enough to bring them to the same level as I2.
In the end, hammer will always dominate i2 in performance per $ just based on the volumes of markets. As time progresses, itanium will ride moore's law wider, whereas it's not clear how hammer will capitalize on die shrinks. Interconnect delay is becoming the dominate issue, and so riding the clock advance like processor makers have been for the last 5 years will not be so straightforward.
I'm earger to by a hammer as well. Don't think I'm somehow badmouthing the chip. Just wanted to balance out over-enthusiastic statements like "it's the fastest thing ever!!!".
Yeah, I'd tend to agree. But, those of us with a couple classes or a couple good books under our belt are different than people who'd like a better understanding, but don't want it enough to go read a couple hundred pages of hennesy and patterson or whoever.
great enthusiasm, but a little mis-informed. As far as spec2k results go, Itanium2 is faster in floating point. And in the real world, "fastest" can vary by individual application, or even the particular inputs you give those applications.
so maybe not "fastest", but it will be fast.
leave it to slashdot to say how stupid something is without bothering to try and understand it.
to the end user, these phones are the same as any other. in this case, optical refers to where the multiplexing is happening: in the media instead of in dsp. it does not mean cell phones using lasers or visible spectrum to transmit data.
Sun is on the wrong end of an economic trend. If they don't re-invent themselves, they'll become trapped in a slowly dieing (heh) nitch.
The fact is, for the enterprise tasks most people would buy sun, these days the tasks parellelize well enough to run them on a cluster of commodity pc hardware. It isn't as reliable, but when you can afford a staggeringly larger number of resources, redundancy becomes very cheap.
Much like vector supercomputers became impactical for most workloads, replaced by beowulf style clusters, sun' hardware will be relegated to areas where massively parellel shared memory architectures are key. The final nail in sun's coffin will be when an x86 chip can address large memories.
perhaps. I personally think it's more likely that nvidia sees the cg software as a complement to commoditize, and as a way to get a home turf advantage. nVidia's focus has been pretty narrow (ie, going vertical being a mistake, etc) so I doubt they'd want to get into the software business.
Indeed, as an IHV, you can add whatever extension to the API you fancy, and software developers are given the option of using it. It is a little frustrating in that you, as a software developer, can't depend on the feature being there, but in practice it works well. For example, ATI and nVidia often update to transparently support eachothers extensions.
Periodicly, the ARB goes through and blesses some extensions, making them official. They're still optional in terms of compliance to the standard, but the ARB blessing catalizes a commonly supported API for each feature.
Eventually a new version of the spec is rolled, and usually the majority of changes were already seen as ARB extensions before.
So, OpenGL has managed a steady evolution. Where it has been slower in reguards to directx is in iterations of revolution. In five years DX went from being bizarre to being very similar to OpenGL, changeing the fundamental philosophy of the API design in the process. Dictatorships allow rapid broad changes like this. OpenGL has not done that so well, which is what the OpenGL 2.0 initiative is a response to.