Come again? I think you misunderstand the details of the situation. The IHV's do not live at MS's pleasure. For example, nvidia's cg is an assult on MS, trying to leverage away their control of the API. Each IHV wants to be able to control the API, so that they can codevelop it with their hardware, producing complimentry strenghts. The relationship is already openly adversarial, and they only co-operate in situations of mutual self benifit.
Your sentance above is unclear, but I understand you're saying that Apple's OpenGL has better hardware support than x86? You do realize that Apple's video chips come from the same IHV's?
There will be no stampede, because there's no business driver for it.
Current providers derive revenue from IP scarcity. It means static ips and ip blocks can be leased for additional $. Even if you don't charge per ip, it's quite typical for static or subnet services to be only on the higher teir accounts that carry a higher profit margin for the service provider.
The only time ip6 will happen is when it's clear to the people with the power that they will make more money allowing lots more devices on the net. But, even this may be unlikely. After all, with the consolodation in telcoms the big boys may try to push their own protocol stack addition that perserves the current revenue.
I think eventually we will have a world with 64bit network addressing, but it's likely that things will get worse before they get better.
Graphics cards and chipsets are expensive. There's just no way around that at. Current graphics chip die sizes make current cpu die sizes seem patheticly small. They have very wide, rather complex memory subsystems. Most graphics cards now are 256 bit bused to memory, that's 4 times what's common on the desktop. That means the pcb cards themselves are quite expensive. The pace of the market is staggeringly fast, a new architecture every year, a process shrink every 6 months. Compare that to AMD having a new architecture every 4 years, and intel every 6 or so. I believe nVidia has 3 parellel design teams in order to keep up the pace of releases. The market simply doesn't forgive anyone who doesn't hit these performance points. Take a look at how little the matrox card is selling.
Some companies are trying to move down. Trident's latest offering is actually quite clever at getting DX9 capability at a very low price.
But the fact is, you've got a low volume market with expensive chips, boards, memory and design, where buyers punish medicre offerings. That's just the way it is. If it were so easy to make a GF4 class card at a sub $100 price point, don't you think someone would have done it by now to rake in the $$?
The TPC-C benchmark is very good, and there are enough multi-cpu results that this should inform you a bit.
In general, for generic database work the important system aspects are: -very large I cache -lots of main memory bandwidth -lots of secondary store bandwidth
This would suggest that a 2x xeon would be better than a cheaper 4x P3 box. While it's impossible for us to give you sizing advice without a more detailed question, my guess would be you need 2 xeon boxes with 4 SCSI disks each in RAID 0-1. One should be enough to run your production work, and I wouldn't personally run MS SQL2k without having a hot backup running as well. It's reliability is a bit better than say, MySQL, but it still will complain now and again. With intel kit, the things that will fail most often will likely be disk controllers and the like, not the SCSI disks, so I'd even chose having a hot backup system over a more reliable RAID setup.
All 64bit machines are actually narrower, and as long as the architecture is spec'd properly, THERE IS NO REASON A LATER CHIP CAN'T ADD MORE PHYSICAL ADDRESS BITS. See the progression the Dec Alpha went through for example.
For the time window the 970 will be in market, a 1TB address space is huge, and saving some bus lines will be a bigger impact by saving bottom line $ than bragging rights over being able to address ram capacities that no one will use.
If you need to address large ram capacities, you're clearly not in the market the 970 is designed for. While geek bragging rights might be fun, apple would have to be as daft as you are to actually bias the price of their product line to achive it.
Re:As long as the compiler is efficient...
on
As Languages Evolve...
·
· Score: 2, Interesting
While it's a general trend that higher abstraction results in lower performance, this isn't always the case. Sometimes you get your cake and eat it too. Templates in c++ are my favorite example... you can get much of the usefulness of virtual classes while not paying as high a price. Ocaml would be another example. It's extremely fast, on par with g++, and yet allows a very high level of abstraction.
I think picking the right tool for the job and the coder/team is most important. This is why java and c++, while covered with warts and sore spots, really are a good thing.
Re:As long as the compiler is efficient...
on
As Languages Evolve...
·
· Score: 2, Interesting
Not always, if the constant factor cost of the O(N) algorithm is much higher, then for a particular set of N's the O(N^2) will be faster.
While complexity analysis is extremely useful, never forget that ultimately, the individual program, machine and input will draw the line between which algorithm is truely faster.
when are you going to learn it's not the tool, it's what someone does with it. people do amazingly photorealistic painting in photoshop and the like all day, without the aid of a renderer simulating light transport. I mean, I'm not trying to say POV-Ray is so good that we can just forget about MR, PRman, Brazil and the like.
What matters is THE GOD DAMN RESULTS, and you can use whatever you want. This guy gets good results with POV-Ray. Far better than the 3 sphere's and checkboard plane crap 99% of people who pirate Maya can make.
I also highly reccomend this book. While I've certainly not pluged the depth of connotation such a short book offers, it's already been very useful. If, as a philosopher you strive for basic, general, unifying principles, this book is a very concise presentation of the same in the arena of programming. It's a shame more people don't read it.
It's Dr. Knuth, and the first edition of the first three volumes are in fact, done. He'll be making 2nd editions sometime in the future after he finishes the volumes he's working on now.
cache's depend on reuse, in this case, there is no reuse, just a predictable stream of information. In other words, the cache doesn't solve the bandwidth problem, just delays it some number of ms until the cache fills. in other words, what you're describing is a fifo.
This is speculation, but I would guess that he's speaking of the first couple chapters of "A Discipline of Programming".
Dijkstra's mindset is not for everyone. It's the mindset of a computer scientist who wants to have confidence in his code, confidence that does not come from ego (I am aswome, therefor my code never stinks).
I think the ugly hack has it's place. After all, breaking a window is usualy a bad way to accomplish something, but if the context is you're trapped in a burning house, it's more likely a good move. Bodgeing it out has a similar context, but 99% of the people who don't value clean, well considered code are not in that context. And of the 1% who are, I would bet many of them are in that burning house because someone before them didn't value clean and well considered code.
It's a bit formal, but Dijkstra's discipline of programing can really deepen your intuative understanding of what programing is all about, and how to be beyond confident your program does what is intended, to be certain of it.
1.) differing focal lengths 2.) synchronization of the film camera and digital camera's mechanisms 3.) form factor limitations fiting into existing cameras 4.) need to customize to many camera lines, leading to a lot of R&D
(disclaimer: I like film, the following is just an analogy, don't get religious over it). Digital film or digital camera backs are much building a mechanical horse to pull a wagon instead of building a car. There are a few situations where they seem to succeed. For example, I've seen Leaf digital backs put to great use in studio use, where many of the limitations can be easily worked around (ie, just use longer shutter or more light).
You are mis-informed. There are plenty of cameras on market in SLR format that provide full optical aperature, focal and shutter control.
Re:have you considered MySQL?
on
PostgreSQL vs. SAP?
·
· Score: 3, Insightful
MySQL is targeted at a particular feature set, and within that feature set, is fast as all heck.
But it is not faster than Postgre or others in all circumstances, and is incredibly slower in many that bear importance to enterprise useage. MySQL provides responses with extremely low latency when there are few concurrent connections. This however, does not scale. It also tends to suffer under certain mixes of statements, or when using particular features.
If you need what I would tend call a "more safe flat file" MySQL is perfect. MySQL also is perfect for some other situations due to it's popularity.
If you need a relational database, potentially large, and that sustains a high number of concurrent connections, PostgreSQL is probibly your best option. While I've not tested the latest flavors of MySQL and Postgre, at the time I did do a comparision, even in 90% simple read queries MySQL's throughput fell below Postgre's after around 10 concurrent connections were reached.
Look, I'm not a Postgre zealot either, but I do feel that many MySQL supports are not familiar with the rest of the database world, that MySQL is all they know, and they try and pull it out as a silver bullet answer to ever problem.
And as others have pointed out, Slashdot is a poor example, they've written a great deal if middleware to deal with MySQL. If writing middleware is something you wanna do, go for it.
The biggest criticism I could level at PostgreSQL is that replication isn't fully implimented yet. This really holds it back from scaling out, again, something important for the enterprise today.
>One. Relying on a single vendor is every bit as dangerous as building a stock "portfolio" with just one stock. Diversity is good.
There's something you're glossing over. For the most part, stocks values are distinct. While a global factor may affect all stocks to some extent, typically the rise or fall of a single stock has a very limited influence on the other stocks in your portfolio. IE, if netscape tanks, it likely won't dent say General Mills.
With solutions however, this isn't always the case. Often a single failure among the componants will bring the entire solution down. This is what makes management nervous, and it's justified and good; don't slam them for it. The way you mitigate this is you make the slices between componants fall on standardized protocols or interfaces. Ie, if MySQL starts to bog or takes a development path away from what you want, if you do things right, it should be quite simple to switch to PostgreSQL or oracle.
So keep that in mind, diversification and combination are not nessisarily the same, and you need to balance the issues.
Not so. Go benchmark. Iostreams often beat printf et all. Not accross the board mind you, my point is merely that it sometimes does, and that accross the board, the performance delta is so slight as to be a non-issue. Review Stroustrup et all's presentation at SD2000, they addressed this issue.
Nothings stoping you from writing it. If you're talking about the intersection of two containers, it would be fairly simple to code in a few lines. Made into a robust reusable thing, not much longer.
You misunderstand the situation. STL, and C++ is not like SQL. You are not given a fixed set of functionality. You are free to write anything you need.
Slashdot Mirror
Come again? I think you misunderstand the details of the situation. The IHV's do not live at MS's pleasure. For example, nvidia's cg is an assult on MS, trying to leverage away their control of the API. Each IHV wants to be able to control the API, so that they can codevelop it with their hardware, producing complimentry strenghts. The relationship is already openly adversarial, and they only co-operate in situations of mutual self benifit.
Your sentance above is unclear, but I understand you're saying that Apple's OpenGL has better hardware support than x86? You do realize that Apple's video chips come from the same IHV's?
Read the various qmail + whatever guides. Also, remember that system tuning can make a difference as well.
There will be no stampede, because there's no business driver for it.
Current providers derive revenue from IP scarcity. It means static ips and ip blocks can be leased for additional $. Even if you don't charge per ip, it's quite typical for static or subnet services to be only on the higher teir accounts that carry a higher profit margin for the service provider.
The only time ip6 will happen is when it's clear to the people with the power that they will make more money allowing lots more devices on the net. But, even this may be unlikely. After all, with the consolodation in telcoms the big boys may try to push their own protocol stack addition that perserves the current revenue.
I think eventually we will have a world with 64bit network addressing, but it's likely that things will get worse before they get better.
Graphics cards and chipsets are expensive. There's just no way around that at. Current graphics chip die sizes make current cpu die sizes seem patheticly small. They have very wide, rather complex memory subsystems. Most graphics cards now are 256 bit bused to memory, that's 4 times what's common on the desktop. That means the pcb cards themselves are quite expensive. The pace of the market is staggeringly fast, a new architecture every year, a process shrink every 6 months. Compare that to AMD having a new architecture every 4 years, and intel every 6 or so. I believe nVidia has 3 parellel design teams in order to keep up the pace of releases. The market simply doesn't forgive anyone who doesn't hit these performance points. Take a look at how little the matrox card is selling.
Some companies are trying to move down. Trident's latest offering is actually quite clever at getting DX9 capability at a very low price.
But the fact is, you've got a low volume market with expensive chips, boards, memory and design, where buyers punish medicre offerings. That's just the way it is. If it were so easy to make a GF4 class card at a sub $100 price point, don't you think someone would have done it by now to rake in the $$?
The TPC-C benchmark is very good, and there are enough multi-cpu results that this should inform you a bit.
In general, for generic database work the important system aspects are:
-very large I cache
-lots of main memory bandwidth
-lots of secondary store bandwidth
This would suggest that a 2x xeon would be better than a cheaper 4x P3 box. While it's impossible for us to give you sizing advice without a more detailed question, my guess would be you need 2 xeon boxes with 4 SCSI disks each in RAID 0-1. One should be enough to run your production work, and I wouldn't personally run MS SQL2k without having a hot backup running as well. It's reliability is a bit better than say, MySQL, but it still will complain now and again. With intel kit, the things that will fail most often will likely be disk controllers and the like, not the SCSI disks, so I'd even chose having a hot backup system over a more reliable RAID setup.
Indeed, if you do the math, it's hard to say trace caches arn't better for the same die area. I expect AMD will go this way sooner or later as well.
All 64bit machines are actually narrower, and as long as the architecture is spec'd properly, THERE IS NO REASON A LATER CHIP CAN'T ADD MORE PHYSICAL ADDRESS BITS. See the progression the Dec Alpha went through for example.
For the time window the 970 will be in market, a 1TB address space is huge, and saving some bus lines will be a bigger impact by saving bottom line $ than bragging rights over being able to address ram capacities that no one will use.
If you need to address large ram capacities, you're clearly not in the market the 970 is designed for. While geek bragging rights might be fun, apple would have to be as daft as you are to actually bias the price of their product line to achive it.
While it's a general trend that higher abstraction results in lower performance, this isn't always the case. Sometimes you get your cake and eat it too. Templates in c++ are my favorite example... you can get much of the usefulness of virtual classes while not paying as high a price. Ocaml would be another example. It's extremely fast, on par with g++, and yet allows a very high level of abstraction.
I think picking the right tool for the job and the coder/team is most important. This is why java and c++, while covered with warts and sore spots, really are a good thing.
Not always, if the constant factor cost of the O(N) algorithm is much higher, then for a particular set of N's the O(N^2) will be faster.
While complexity analysis is extremely useful, never forget that ultimately, the individual program, machine and input will draw the line between which algorithm is truely faster.
when are you going to learn it's not the tool, it's what someone does with it. people do amazingly photorealistic painting in photoshop and the like all day, without the aid of a renderer simulating light transport. I mean, I'm not trying to say POV-Ray is so good that we can just forget about MR, PRman, Brazil and the like.
What matters is THE GOD DAMN RESULTS, and you can use whatever you want. This guy gets good results with POV-Ray. Far better than the 3 sphere's and checkboard plane crap 99% of people who pirate Maya can make.
I also highly reccomend this book. While I've certainly not pluged the depth of connotation such a short book offers, it's already been very useful. If, as a philosopher you strive for basic, general, unifying principles, this book is a very concise presentation of the same in the arena of programming. It's a shame more people don't read it.
It's Dr. Knuth, and the first edition of the first three volumes are in fact, done. He'll be making 2nd editions sometime in the future after he finishes the volumes he's working on now.
cache's depend on reuse, in this case, there is no reuse, just a predictable stream of information. In other words, the cache doesn't solve the bandwidth problem, just delays it some number of ms until the cache fills. in other words, what you're describing is a fifo.
This is speculation, but I would guess that he's speaking of the first couple chapters of "A Discipline of Programming".
Dijkstra's mindset is not for everyone. It's the mindset of a computer scientist who wants to have confidence in his code, confidence that does not come from ego (I am aswome, therefor my code never stinks).
I think the ugly hack has it's place. After all, breaking a window is usualy a bad way to accomplish something, but if the context is you're trapped in a burning house, it's more likely a good move. Bodgeing it out has a similar context, but 99% of the people who don't value clean, well considered code are not in that context. And of the 1% who are, I would bet many of them are in that burning house because someone before them didn't value clean and well considered code.
and in some cases, it's still relavant, ie constricted embeded systems, low cost devices, etc.
as for mix being outdated, it's being passed aside for an updated version (mmix).
I don't think AoCP will ever truely become outdated until Knuth dies and isn't around any more to rewrite it.
But even then, algorithms don't change, perhaps their relavance changes, but there's still value to learning the landscape.
It's a bit formal, but Dijkstra's discipline of programing can really deepen your intuative understanding of what programing is all about, and how to be beyond confident your program does what is intended, to be certain of it.
1.) differing focal lengths
2.) synchronization of the film camera and digital camera's mechanisms
3.) form factor limitations fiting into existing cameras
4.) need to customize to many camera lines, leading to a lot of R&D
(disclaimer: I like film, the following is just an analogy, don't get religious over it). Digital film or digital camera backs are much building a mechanical horse to pull a wagon instead of building a car. There are a few situations where they seem to succeed. For example, I've seen Leaf digital backs put to great use in studio use, where many of the limitations can be easily worked around (ie, just use longer shutter or more light).
You are mis-informed. There are plenty of cameras on market in SLR format that provide full optical aperature, focal and shutter control.
MySQL is targeted at a particular feature set, and within that feature set, is fast as all heck.
But it is not faster than Postgre or others in all circumstances, and is incredibly slower in many that bear importance to enterprise useage. MySQL provides responses with extremely low latency when there are few concurrent connections. This however, does not scale. It also tends to suffer under certain mixes of statements, or when using particular features.
If you need what I would tend call a "more safe flat file" MySQL is perfect. MySQL also is perfect for some other situations due to it's popularity.
If you need a relational database, potentially large, and that sustains a high number of concurrent connections, PostgreSQL is probibly your best option. While I've not tested the latest flavors of MySQL and Postgre, at the time I did do a comparision, even in 90% simple read queries MySQL's throughput fell below Postgre's after around 10 concurrent connections were reached.
Look, I'm not a Postgre zealot either, but I do feel that many MySQL supports are not familiar with the rest of the database world, that MySQL is all they know, and they try and pull it out as a silver bullet answer to ever problem.
And as others have pointed out, Slashdot is a poor example, they've written a great deal if middleware to deal with MySQL. If writing middleware is something you wanna do, go for it.
The biggest criticism I could level at PostgreSQL is that replication isn't fully implimented yet. This really holds it back from scaling out, again, something important for the enterprise today.
>One. Relying on a single vendor is every bit as dangerous as building a stock "portfolio" with just one stock. Diversity is good.
There's something you're glossing over. For the most part, stocks values are distinct. While a global factor may affect all stocks to some extent, typically the rise or fall of a single stock has a very limited influence on the other stocks in your portfolio. IE, if netscape tanks, it likely won't dent say General Mills.
With solutions however, this isn't always the case. Often a single failure among the componants will bring the entire solution down. This is what makes management nervous, and it's justified and good; don't slam them for it. The way you mitigate this is you make the slices between componants fall on standardized protocols or interfaces. Ie, if MySQL starts to bog or takes a development path away from what you want, if you do things right, it should be quite simple to switch to PostgreSQL or oracle.
So keep that in mind, diversification and combination are not nessisarily the same, and you need to balance the issues.
Not so. Go benchmark. Iostreams often beat printf et all. Not accross the board mind you, my point is merely that it sometimes does, and that accross the board, the performance delta is so slight as to be a non-issue. Review Stroustrup et all's presentation at SD2000, they addressed this issue.
WTF are you talking about? Unless you're using a dodgy implimentation, I'd take STL's code over some random wankers any day.
STL is all about _free_ abstraction. You do pay for longer compile times, but c++ templates well applied can offer blistering speed.
Nothings stoping you from writing it. If you're talking about the intersection of two containers, it would be fairly simple to code in a few lines. Made into a robust reusable thing, not much longer.
You misunderstand the situation. STL, and C++ is not like SQL. You are not given a fixed set of functionality. You are free to write anything you need.
Which implimentation? STL is a standard, there are at least 50 seperate implimentations. All the ones I've used have been bulletproof.
Don't be an idiot, think about what you post next time.
He's most likely refering to J2EE Beans or other componant systems.
This is clear an apples to oranges issue. STL provides standard facilities, you can use it alongside with whatever componant technology you please.