Re:32-bit compatible = a temporary half-solution
on
AMD's 64-bit Plot
·
· Score: 2
1) Reliance on the fact that size of pointer is equal to size of int.
2) Reliance on a particular byte order in the machine word.
3) Using type long and presuming that it always has the same size as int.
4) Alignment of stack variables.
5) Different alignment rules in structures and classes.
6) Pointer arithmetic.
With regard to points 1, 2, and 3: Only exceptionally hacky programmers would ever do these things. Even the first edition of "The C Programming Language" states clearly that you should never do them. It also states that you should always use "sizeof (int)" rather than 4 (32 bits), etc. It also states that a long should never be assumed to be the same size as an int. Only very poorly written programs would present any difficulty when re-compiling for 64 bits.
Points 4, 5, and 6: These things are handled automatically by the compiler. If an int is 8 bytes, the compiler automatically multiplies by 8 rather than 4.
32 bit architectures are not limited to 4 gigabytes of memory. "32 bit processor" refers to the width of the DATA bus (and registers). It does not refer to the width of the address bus.
For example, the z80 and 6502 were 8-bit processors, but they supported more than 256 bytes of RAM (2^8 bytes). The 68000 and 80286 were 16-bit processors, but they supported more than 64k of RAM (2^16 bytes). That's because the 8-bit processors had 16-bit address busses, and the 16-bit processors often had 24-bit address busses.
The current pentium-4 Xeon chip supports 64 gig of RAM, despite being a 32-bit processor.
64-bit computing means that you can hold a 64-bit quantity (long int or double) in a register. Also, you can load, store, or perform arithmetic on such quantities using one instruction and often in one clock cycle.
This offers very few benefits for the end consumer. Mostly it's about perception: consumers will percieve that a 64-bit chip is twice as good as a 32-bit one.
The number of years is important. 90% of businesses fail within the first 3 years; 99% within 8 years. Most people quote that "more than 90% of businesses fail", however if you follow the businesses further along down the road, the statistic becomes more grim.
it's a wonder anyone makes a living at all.
Of course, 0.001% of businesses become Microsoft or IBM, and end up employing 80,000 people.
I have a couple of points to counteract the vast slew of nonsense that has been posted here.
First: "It's not fair that the boss makes more money than I do. I work all day long, and he sits around and gets a ferrari."
The boss does not sit around and do nothing and get a free ferrari. 99% of small businesses fail within 8 years; this implies that the successful small businessman is providing a service that 99% of people who tried were incapable of providing. If running a company were so easy, and a ferrari were guaranteed, then everyone would do it.
The fact is, small business owners subsidize both employees and consumers. This is a well-known economic fact. They do not intend to do this; they wrongly think that running a business is easier than it is, and they end up bankrupting themselves while paying employees and consumers. It is simply not true that the small business owner is "exploiting" you.
Another point I should take issue with: "It's not fair that I'm only paid $80k per year. My company is exploiting me and driving down the price of my labor, so that my bosses can greedily increase their profit margins."
Fact: the average profit margin in large U.S. businesses is 4%. That profit margin is not blown on ferraris; it goes to expanding the business. In short, there is no extra money. Your livelihood is not being stolen and sucked up in greedy profits. In order to increase your salaries, business would have to raise prices, which would make everyone else in this economy poorer. And don't say: "we can just take money away from executives!" Executives do something that you could not do. If being an executive were so easy, companies would fire them and replace them with someone less expensive. Comapnies don't want to blow money on execs any more than on anything else; the only reason execs are paid alot is because they render a service that few others can provide.
And a final point: "Look at the fruits of evil capitalism. I am only paid $80k per year, and I am forced to work, and my job leads to loneliness, etc. Capitalism has done this!"
A typical salary before capitalism was ~$800/year. That is what the salary still is in communist China. You are paid 100 times that amount. Capitalism has led to a phenomenal increase in the standard of living; NOTHING ELSE could have done this.
All of this demonstrates a few basic points:
1. Slashdotters, and people in general, are radically ignorant of both business and economics.
2. Their suggested "improvements" would wreck the phenomenal machinery that provides them with a fantastic living. The masses go in search of more food, and the methods they employ are generally to wreck the bakeries.
Profitability... is tough to gauge frrom a balance sheet. Productivity is hard to quantify... R&D costs are hard to quantify...
You do not need to quantify productivity, to determine your profits. You need only subtract the sales price from your costs; how productive they were does not factor in to this equation.
R&D costs are very easy to quantify. Add up the amount you paid your R&D employees, plus their expenses and the costs for the buildings etc. The eventual value is difficult to quantify, but that is not the issue here.
How much do you think a cup of coffee costs Starbucks to brew? After you take into account the cost of coffee, the cost of the $1 million building, the advertisements, the store managers, the employees, and so on, a cup of coffee is quite expensive. Starbucks has about an 8% profit margin (finance.yahoo.com).
First, there were about 10 people who made points like these: Mcdonald's charges $1.25 for a large coke when it only costs them $0.03. Diamond retailers have a 200% markup. Vending machines sell coke for $0.75/can when it costs $0.10 to manufacture. Look at how big their profit margins are! And so on...
The profit margins at Mcdonald's, jewelry retailers, and vending machine companies are very low. You have to take into account all the costs in calculating profit. Mcdonald's only pays $0.03 for the coke they are selling you, but they paid over $1 million for the building in which they are selling it to you, and over $200k/yr for employees in that building, plus costs for managers and benefits, to say nothing of corporate expenses, advertisements, and so on. Retail jewelry stores fail more often than any other kind of store. Sure, they charge a 100% markup, but they get like 2 paying customers per day, for which they must pay rent on a store and employees' salaries, etc.
An 89% profit margin is extremely unusual. IIRC, the average profit margin in American business is around 4%. The only other large companies that take anywhere near that profit are drug companies, right after marketing a "blockbuster drug" where there few competitive alternatives.
1. SMT will become vastly more important as time progresses. This is the first iteration only. Being able to dispatch multiple threads to various pipelines, will grow increasingly more important as the number of pipelines in a CPU naturally increases. What happens when CPUs have 400 mil transistors, and 16 integer pipelines? There is no more instruction-level parallelism to exploit; the only way to get any more parallelism is at the THREAD level. In the future, we should expect to see CPUs with >4 thread contexts that perform at least 2x as well as single-context CPUs.
2. Hyperthreading does not just "hold 1 app in the hole, ready to run [during downtime]". Hyperthreading can dispatch instructions from multiple threads to various execution units simultaneously.
XP entirely consists of about 20 helpful programming tips:
"write unit tests first."
"leave optimization 'till last."
"develop iteratively."
...and so on. These helpful pointers are treated as if they were the ripest wisdom, but actually they're just common sense. They're obvious to anyone who isn't retarded. The few things in XP that are controversial (like pair programming) don't work.
The importance of XP is exaggerated to an incredible extent. I've heard more than one person compare XP to OO! Consider the vast amount of thinking of research that went into the development of OO. XP is comparable in importance to a "Frequently Asked Questions" file for beginning programmers.
The article benchmarks are for _bandwidth_, which is irrelevant. Mechanical disks get good bandwidth already (The RAM drive only gets 2x as much). What matters is _latency_; disk latency is about 1,000x as great as RAM latency.
Some applications are latency-intensive, for example, OLTP and other database applications. Databases don't care about bandwidth; they care about latency. And just "adding more memory" will NOT work because database transactions do not complete until a record is written to NON-VOLATILE storage. (Losing committed transactions after a power failure is unacceptable).
At present, all the big database boxes have like 500+ drives. Why? They don't have nearly that much data. The reason is because lots of disks working in parallel mitigate the terrible seek times of mechanical drives. Lots of read/write heads seeking in PARALLEL, each over a small portion of data, leads to much better seek times. However, a SINGLE RAM drive would provide FAR better seek times than all those mechanical units working in parallel.
At present, companies spend millions of dollars on huge drive arrays, not because they need more space, but because they want to mitigate terrible seek times. A RAM drive is faster and cheaper than this.
The only reason _this_ ram drive would not work is because it is not really "non-volatile". With a database, the data _cannot_ be lost. An internal "battery backup" is not sufficient. (How long will the battery last? Can you really be guaranteed that all the data can be copied to disk? etc).
A RAM drive that had truly non-volatile RAM and that was in the 20GB range would sell to owners of large databases, even if the drives were very expensive. The technology probably exists to do this now.
You shouldn't insult the poster for being an ignorant moron, when your own knowledge of these issues is not adequate.
The p4 20-stage pipeline has to be flushed _whenever_ there is a branch misprediction. Since there is a branch every 6 instructions (on average), misprediction is not an uncommon scenario. An FP instruction followed by a branch directly afterward could very easily take 20 cycles.
The MIPS architecture has 32 general purpose registers and 32 64-bit FP registers (MIPS r4000 user's manual, pp 154). They _cannot_ be used "any way you want." Mips therefore has 64 registers, which is far more than x86. Even this is misleading however, because x86 converts instructions into micro-ops which have 128 GPRs mapped to the traditional 8 regs, but I digress..
Although cache enhances memory access speed, it is still quite slow compared to registers (often >25 cycles).
You should be more polite when responding to posts.
By now I have interviewed several hundred programmers; some of them worked out, others didn't. I've found the following to be the most successful interview technique.
First, do not ask a standard set of questions. Standard CS questions are known by almost everybody, even wrotten programmers. "How do you implement a linked list" will not assure you a good programmer. Pick an area in which the applicant claims to have significant expertise and understanding. Then, ask increasingly difficult questions about _that topic_ until they can't answer all your questions any more. This gives a good indication of the level of technological sophistication.
Furthermore, ask WHY. "What is the purpose of third normal form?" is a _vastly_ better question than just asking what is third normal form. Everyone knows what third normal form is. Asking why allows the programmer to demonstrate genuine understanding. Not so many people understand the rationale behind the trivial facts they've memorized. Anyone can memorize facts; fewer people can understand.
Also, look for a background of challenging projects. People who have had significant roles in successful, challenging projects are generally good programmers.
Finally, don't ask questions that are only relevant to yourself!! Several commentators here have said you should ask "Which open-source projects have you contributed to," and judge based on that. Because you are an OSS advocate does not mean that OSS people are the best programmers (they often aren't). Some people here have said you should ask "Explain (blank) algorithm in detail..." when that algorithm relates to speech processing or compression etc. That's YOUR area of expertise. Ask them about THEIR area of expertise.
> Well, that is true, and those tools often cut the time taken to fix a memory leak down to > minutes or seconds. That said, something that rang very true in the cited article was that > Java tends to be more productive for less experienced programmers, then C++ catches up > and overtakes it as programmer experience goes up.
I'd be quite surprised if C++ programmers would ever _overtake_ Java programmers in productivity. The biggest difference between the two languages is that Java manages some things for you (garbage collection, etc).
> Certainly the average C++ programmer does plenty of dumb things (like using raw pointers > and arrays, new and delete all over the place, etc) that a more experienced programmer would > simply avoid altogether except in the low-level code where they're justified. That same more > experienced programmer is probably smart enough to put in lots of diagnostics to make sure his > low level code is rock solid, and as a consequence of these arrangements, he'll usually > suffer from no resource leaks at all. In the usual great irony, a less experienced programmer > would be more confident in his skill, and probably litter his code with bad style, leading > straight to the sort of bugs that Java would prevent.
I don't buy the the argument: "I have experience, so my programs don't have those bugs." I have never met a programmer with sufficient experience to write large, complicated programs that are correct on the first try. Garbage collection eliminates an entire class of bugs automatically. You state the the programmer could put in "lots of diagnostics" to make sure that there are no memory leaks, but even this takes programmer time.
The "usual great irony" you mention is absolutely correct: inexperienced programmers are far more confident in their ability to write bugless code.
> A special syntax since it acts very much like > a structure. And, as the Sun docs [sun.com] > state, "Arrays are supported directly by the > Java programming language; there is no array > class. Arrays are implicit extensions of the > Object class, so you can assign an array to a > variable whose type is declared as Object." > There is no class to implement the length > member like the original poster wanted. > Implicit isn't quite the same as is, IMO.
This point is clearly debatable. I suppose it is reasonable to say that arrays are not objects.
The article that you cited was extraordinarily biased in favor of C++.
There is a great deal of independent research showing that equivalent programmers are more productive in Java over C++.
The cited article indicates that it takes the same amount of time to _write_ a program in C++ or Java, but the article dismisses the amount of time it takes to debug those programs. The article admits that debugging memory leaks is nasty and time-consuming, but states that "tools exist to help the programmer with this."
Those tools do not remove the problem. Debugging memory leaks is incredibly time-consuming. Notice that a many commercial products _ship_ with a great many active memory leaks. Even some operating systems have them (Irix 5).
> Pointers and direct memory access: Java > currently makes it very difficult to write > specific machine-targeted instructions. I find > it frustrating that I can't wring out every > last bit of performance from whatever CPU I'm > coding for. The designers of Java really blew > that one. Direct memory access with pointers > like in Visual Basic and Delphi would be a > godsend.
The _very point_ of java is _never_ to do this!! If you want to use direct access to optimize every last clock cycle, don't use java!
> An Array is not an object. You merely are > accessing a data field in its structure which > is R/O.
Incorrect. An array is an object with special syntax. Every array is an instance of java.lang.Object. There are no "structures" in java. Try this:
System.out.println("Arrays are objects?" + (new int[] {1,2,3} instanceof Object));
> If you don't want to mess around with > "dirty details," stick to pure CS languages. > In the RealWorld(TM), you write code that > deals with things.
Not messing around with "dirty details" is one of the goals of almost every language.
> Write a class which does all the nitty gritty > in an easy-to-use interface, and use only that > interface. Make it generic and useful, and > you'll be able to re-use that object in all > your projects.
> Templates can work better (less code to write) > for small situations....
Templates are _not_ meant as a substitute for polymorphism! The two are _not_ related!! I keep seeing this brought up. Templates are meant to resolve the current type unsafety of collections (and related) classes! This is a problem that _cannot_ be solved with polymorphism. Polymorphism and generics are not the same thing and do not exist for the same purpose!!
Your post is a bunch of random nasty assertions with no supporting logic whatsoever.
> Generics are pointless.... break type safety..
Generics BREAK type safety? At present, objects are retrieved from a collection by typecasting them! Collections are already absolutely type-unsafe. Generics are to FIX this problem. How do generics ruin type safety?
>...they are a crutch for people who do not > understand polymorphism.
What? Generics have nothing to do with polymorphism. They don't break polymorphism, and polymorphism does not provide the mechanism that generics provide.
> I don't think getting rid of primitives is > realistic.
It is very realistic; it has been done successfully in several languages.
> What would you use to index > arrays with? Objects?
You would index arrays with integers (objects).
> So arrays would > inherently be hash maps? What kind of > performance impact would that have?
No, an array would not be a hash map. A hash map allows dynamic insertions/deletions and stores by a hashing function, whereas an array is a continuous region of memory. Objects would present no performance impact, since the compiler could easily "convert" the object integer index into a primitive as necessary.
Although I am not entirely certain, I don't believe you are correct about this. Postgres did innovate a lot of features in the database world, particularly the notion of the "active database" (triggers, etc). Postgres also innovated some other things that have never appeared elsewhere (time travel).
I know that postgres has the ability for you to define your own types, but I am not certain about the extent of its object-relational capabilities.
Although PostgreSQL is vastly superior to MySQL, it is still nowhere near being on par with Oracle. Oracle has an incredible number of features that are lacking in PostgreSQL. A few of them are:
1. Hot Backups. This does NOT just mean a "consistent snapshot" as postgres provides; it implies a backup manager that can successively apply transactions from a redo log.
2. Asynchronous replication, parallel server, and hot standbys. You claim that postgres does replication however a search for 'replication' on the PostgreSQL mirrors yields no information.
These are just the heavily-used enterprise features; if I listed all the obscure features of Oracle, this post would be very long.
> If PostgreSQL could magically don an Oracular > CIO-level reputation, the bottom half - or > more - of the Oracle market would evapourate > in a few short years.
Oracle Standard Edition is $300 per user. Most corporations would not want to "downgrade" to save $300, since their database is usually a rather criticial part of their operation.
For a webiste, however, you would have to buy an unlimited license ($15,000). For a small website, postgres is clearly a superior choice.
On this point I disagree completely. CVS has the best documentation of almost any open source project I've seen. Cederqvist wrote a significant book on the subject, which is open source and freely redistributed. Typing "info cvs" brings up documentation that is coherent, explanatory, cross-referenced, and organized.
Most open source projects have documentation that is a few pages of badly written english. Usually that documentation answers no questions and provides no information.
I'm curious to know exactly what your complaints are about the current cvs documentation.
Slashdot Mirror
1) Reliance on the fact that size of pointer is equal to size of int.
2) Reliance on a particular byte order in the machine word.
3) Using type long and presuming that it always has the same size as int.
4) Alignment of stack variables.
5) Different alignment rules in structures and classes.
6) Pointer arithmetic.
With regard to points 1, 2, and 3: Only exceptionally hacky programmers would ever do these things. Even the first edition of "The C Programming Language" states clearly that you should never do them. It also states that you should always use "sizeof (int)" rather than 4 (32 bits), etc. It also states that a long should never be assumed to be the same size as an int. Only very poorly written programs would present any difficulty when re-compiling for 64 bits.
Points 4, 5, and 6: These things are handled automatically by the compiler. If an int is 8 bytes, the compiler automatically multiplies by 8 rather than 4.
32 bit architectures are not limited to 4 gigabytes of memory. "32 bit processor" refers to the width of the DATA bus (and registers). It does not refer to the width of the address bus.
For example, the z80 and 6502 were 8-bit processors, but they supported more than 256 bytes of RAM (2^8 bytes). The 68000 and 80286 were 16-bit processors, but they supported more than 64k of RAM (2^16 bytes). That's because the 8-bit processors had 16-bit address busses, and the 16-bit processors often had 24-bit address busses.
The current pentium-4 Xeon chip supports 64 gig of RAM, despite being a 32-bit processor.
64-bit computing means that you can hold a 64-bit quantity (long int or double) in a register. Also, you can load, store, or perform arithmetic on such quantities using one instruction and often in one clock cycle.
This offers very few benefits for the end consumer. Mostly it's about perception: consumers will percieve that a 64-bit chip is twice as good as a 32-bit one.
The number of years is important. 90% of businesses fail within the first 3 years; 99% within 8 years. Most people quote that "more than 90% of businesses fail", however if you follow the businesses further along down the road, the statistic becomes more grim.
it's a wonder anyone makes a living at all.
Of course, 0.001% of businesses become Microsoft or IBM, and end up employing 80,000 people.
I have a couple of points to counteract the vast slew of nonsense that has been posted here.
First: "It's not fair that the boss makes more money than I do. I work all day long, and he sits around and gets a ferrari."
The boss does not sit around and do nothing and get a free ferrari. 99% of small businesses fail within 8 years; this implies that the successful small businessman is providing a service that 99% of people who tried were incapable of providing. If running a company were so easy, and a ferrari were guaranteed, then everyone would do it.
The fact is, small business owners subsidize both employees and consumers. This is a well-known economic fact. They do not intend to do this; they wrongly think that running a business is easier than it is, and they end up bankrupting themselves while paying employees and consumers. It is simply not true that the small business owner is "exploiting" you.
Another point I should take issue with: "It's not fair that I'm only paid $80k per year. My company is exploiting me and driving down the price of my labor, so that my bosses can greedily increase their profit margins."
Fact: the average profit margin in large U.S. businesses is 4%. That profit margin is not blown on ferraris; it goes to expanding the business. In short, there is no extra money. Your livelihood is not being stolen and sucked up in greedy profits. In order to increase your salaries, business would have to raise prices, which would make everyone else in this economy poorer. And don't say: "we can just take money away from executives!" Executives do something that you could not do. If being an executive were so easy, companies would fire them and replace them with someone less expensive. Comapnies don't want to blow money on execs any more than on anything else; the only reason execs are paid alot is because they render a service that few others can provide.
And a final point: "Look at the fruits of evil capitalism. I am only paid $80k per year, and I am forced to work, and my job leads to loneliness, etc. Capitalism has done this!"
A typical salary before capitalism was ~$800/year. That is what the salary still is in communist China. You are paid 100 times that amount. Capitalism has led to a phenomenal increase in the standard of living; NOTHING ELSE could have done this.
All of this demonstrates a few basic points:
1. Slashdotters, and people in general, are radically ignorant of both business and economics.
2. Their suggested "improvements" would wreck the phenomenal machinery that provides them with a fantastic living. The masses go in search of more food, and the methods they employ are generally to wreck the bakeries.
Profitability ... is tough to gauge frrom a balance sheet. Productivity is hard to quantify... R&D costs are hard to quantify...
You do not need to quantify productivity, to determine your profits. You need only subtract the sales price from your costs; how productive they were does not factor in to this equation.
R&D costs are very easy to quantify. Add up the amount you paid your R&D employees, plus their expenses and the costs for the buildings etc. The eventual value is difficult to quantify, but that is not the issue here.
How much do you think a cup of coffee costs Starbucks to brew?
After you take into account the cost of coffee, the cost of the $1 million building, the advertisements, the store managers, the employees, and so on, a cup of coffee is quite expensive. Starbucks has about an 8% profit margin (finance.yahoo.com).
First, there were about 10 people who made points like these: Mcdonald's charges $1.25 for a large coke when it only costs them $0.03. Diamond retailers have a 200% markup. Vending machines sell coke for $0.75/can when it costs $0.10 to manufacture. Look at how big their profit margins are! And so on...
The profit margins at Mcdonald's, jewelry retailers, and vending machine companies are very low. You have to take into account all the costs in calculating profit. Mcdonald's only pays $0.03 for the coke they are selling you, but they paid over $1 million for the building in which they are selling it to you, and over $200k/yr for employees in that building, plus costs for managers and benefits, to say nothing of corporate expenses, advertisements, and so on. Retail jewelry stores fail more often than any other kind of store. Sure, they charge a 100% markup, but they get like 2 paying customers per day, for which they must pay rent on a store and employees' salaries, etc.
An 89% profit margin is extremely unusual. IIRC, the average profit margin in American business is around 4%. The only other large companies that take anywhere near that profit are drug companies, right after marketing a "blockbuster drug" where there few competitive alternatives.
SMT is not "hype for sheep."
1. SMT will become vastly more important as time progresses. This is the first iteration only. Being able to dispatch multiple threads to various pipelines, will grow increasingly more important as the number of pipelines in a CPU naturally increases. What happens when CPUs have 400 mil transistors, and 16 integer pipelines? There is no more instruction-level parallelism to exploit; the only way to get any more parallelism is at the THREAD level. In the future, we should expect to see CPUs with >4 thread contexts that perform at least 2x as well as single-context CPUs.
2. Hyperthreading does not just "hold 1 app in the hole, ready to run [during downtime]". Hyperthreading can dispatch instructions from multiple threads to various execution units simultaneously.
I don't think that sparc is an SMT variant, however I think that MAJC might have had some form of SMT.
The IBM POWER RS64 that was used in the S/80s, was an SMT chip. All of those bigass IBM unix machines sold during that era had SMT.
XP entirely consists of about 20 helpful programming tips:
...and so on. These helpful pointers are treated as if they were the ripest wisdom, but actually they're just common sense. They're obvious to anyone who isn't retarded. The few things in XP that are controversial (like pair programming) don't work.
"write unit tests first."
"leave optimization 'till last."
"develop iteratively."
The importance of XP is exaggerated to an incredible extent. I've heard more than one person compare XP to OO! Consider the vast amount of thinking of research that went into the development of OO. XP is comparable in importance to a "Frequently Asked Questions" file for beginning programmers.
The article benchmarks are for _bandwidth_, which is irrelevant. Mechanical disks get good bandwidth already (The RAM drive only gets 2x as much). What matters is _latency_; disk latency is about 1,000x as great as RAM latency.
Some applications are latency-intensive, for example, OLTP and other database applications. Databases don't care about bandwidth; they care about latency. And just "adding more memory" will NOT work because database transactions do not complete until a record is written to NON-VOLATILE storage. (Losing committed transactions after a power failure is unacceptable).
At present, all the big database boxes have like 500+ drives. Why? They don't have nearly that much data. The reason is because lots of disks working in parallel mitigate the terrible seek times of mechanical drives. Lots of read/write heads seeking in PARALLEL, each over a small portion of data, leads to much better seek times. However, a SINGLE RAM drive would provide FAR better seek times than all those mechanical units working in parallel.
At present, companies spend millions of dollars on huge drive arrays, not because they need more space, but because they want to mitigate terrible seek times. A RAM drive is faster and cheaper than this.
The only reason _this_ ram drive would not work is because it is not really "non-volatile". With a database, the data _cannot_ be lost. An internal "battery backup" is not sufficient. (How long will the battery last? Can you really be guaranteed that all the data can be copied to disk? etc).
A RAM drive that had truly non-volatile RAM and that was in the 20GB range would sell to owners of large databases, even if the drives were very expensive. The technology probably exists to do this now.
You shouldn't insult the poster for being an ignorant moron, when your own knowledge of these issues is not adequate.
The p4 20-stage pipeline has to be flushed _whenever_ there is a branch misprediction. Since there is a branch every 6 instructions (on average), misprediction is not an uncommon scenario. An FP instruction followed by a branch directly afterward could very easily take 20 cycles.
The MIPS architecture has 32 general purpose registers and 32 64-bit FP registers (MIPS r4000 user's manual, pp 154). They _cannot_ be used "any way you want." Mips therefore has 64 registers, which is far more than x86. Even this is misleading however, because x86 converts instructions into micro-ops which have 128 GPRs mapped to the traditional 8 regs, but I digress..
Although cache enhances memory access speed, it is still quite slow compared to registers (often >25 cycles).
You should be more polite when responding to posts.
By now I have interviewed several hundred programmers; some of them worked out, others didn't. I've found the following to be the most successful interview technique.
First, do not ask a standard set of questions. Standard CS questions are known by almost everybody, even wrotten programmers. "How do you implement a linked list" will not assure you a good programmer. Pick an area in which the applicant claims to have significant expertise and understanding. Then, ask increasingly difficult questions about _that topic_ until they can't answer all your questions any more. This gives a good indication of the level of technological sophistication.
Furthermore, ask WHY. "What is the purpose of third normal form?" is a _vastly_ better question than just asking what is third normal form. Everyone knows what third normal form is. Asking why allows the programmer to demonstrate genuine understanding. Not so many people understand the rationale behind the trivial facts they've memorized. Anyone can memorize facts; fewer people can understand.
Also, look for a background of challenging projects. People who have had significant roles in successful, challenging projects are generally good programmers.
Finally, don't ask questions that are only relevant to yourself!! Several commentators here have said you should ask "Which open-source projects have you contributed to," and judge based on that. Because you are an OSS advocate does not mean that OSS people are the best programmers (they often aren't). Some people here have said you should ask "Explain (blank) algorithm in detail..." when that algorithm relates to speech processing or compression etc. That's YOUR area of expertise. Ask them about THEIR area of expertise.
> Well, that is true, and those tools often cut the time taken to fix a memory leak down to
> minutes or seconds. That said, something that rang very true in the cited article was that
> Java tends to be more productive for less experienced programmers, then C++ catches up
> and overtakes it as programmer experience goes up.
I'd be quite surprised if C++ programmers would ever _overtake_ Java programmers in productivity. The biggest difference between the two languages is that Java manages some things for you (garbage collection, etc).
> Certainly the average C++ programmer does plenty of dumb things (like using raw pointers
> and arrays, new and delete all over the place, etc) that a more experienced programmer would
> simply avoid altogether except in the low-level code where they're justified. That same more
> experienced programmer is probably smart enough to put in lots of diagnostics to make sure his
> low level code is rock solid, and as a consequence of these arrangements, he'll usually
> suffer from no resource leaks at all. In the usual great irony, a less experienced programmer
> would be more confident in his skill, and probably litter his code with bad style, leading
> straight to the sort of bugs that Java would prevent.
I don't buy the the argument: "I have experience, so my programs don't have those bugs." I have never met a programmer with sufficient experience to write large, complicated programs that are correct on the first try. Garbage collection eliminates an entire class of bugs automatically. You state the the programmer could put in "lots of diagnostics" to make sure that there are no memory leaks, but even this takes programmer time.
The "usual great irony" you mention is absolutely correct: inexperienced programmers are far more confident in their ability to write bugless code.
> A special syntax since it acts very much like
> a structure. And, as the Sun docs [sun.com]
> state, "Arrays are supported directly by the
> Java programming language; there is no array
> class. Arrays are implicit extensions of the
> Object class, so you can assign an array to a
> variable whose type is declared as Object."
> There is no class to implement the length
> member like the original poster wanted.
> Implicit isn't quite the same as is, IMO.
This point is clearly debatable. I suppose it is reasonable to say that arrays are not objects.
The article that you cited was extraordinarily biased in favor of C++.
There is a great deal of independent research showing that equivalent programmers are more productive in Java over C++.
The cited article indicates that it takes the same amount of time to _write_ a program in C++ or Java, but the article dismisses the amount of time it takes to debug those programs. The article admits that debugging memory leaks is nasty and time-consuming, but states that "tools exist to help the programmer with this."
Those tools do not remove the problem. Debugging memory leaks is incredibly time-consuming. Notice that a many commercial products _ship_ with a great many active memory leaks. Even some operating systems have them (Irix 5).
> Pointers and direct memory access: Java
> currently makes it very difficult to write
> specific machine-targeted instructions. I find
> it frustrating that I can't wring out every
> last bit of performance from whatever CPU I'm
> coding for. The designers of Java really blew
> that one. Direct memory access with pointers
> like in Visual Basic and Delphi would be a
> godsend.
The _very point_ of java is _never_ to do this!! If you want to use direct access to optimize every last clock cycle, don't use java!
> An Array is not an object. You merely are
> accessing a data field in its structure which
> is R/O.
Incorrect. An array is an object with special syntax. Every array is an instance of java.lang.Object. There are no "structures" in java. Try this:
System.out.println("Arrays are objects?" + (new int[] {1,2,3} instanceof Object));
> If you don't want to mess around with
> "dirty details," stick to pure CS languages.
> In the RealWorld(TM), you write code that
> deals with things.
Not messing around with "dirty details" is one of the goals of almost every language.
> Write a class which does all the nitty gritty
> in an easy-to-use interface, and use only that
> interface. Make it generic and useful, and
> you'll be able to re-use that object in all
> your projects.
I think people know this already.
> OO has a great feature called polymorphism.
> Templates can work better (less code to write)
> for small situations....
Templates are _not_ meant as a substitute for polymorphism! The two are _not_ related!! I keep seeing this brought up. Templates are meant to resolve the current type unsafety of collections (and related) classes! This is a problem that _cannot_ be solved with polymorphism. Polymorphism and generics are not the same thing and do not exist for the same purpose!!
Your post is a bunch of random nasty assertions with no supporting logic whatsoever.
...they are a crutch for people who do not
> Generics are pointless.... break type safety..
Generics BREAK type safety? At present, objects are retrieved from a collection by typecasting them! Collections are already absolutely type-unsafe. Generics are to FIX this problem. How do generics ruin type safety?
>
> understand polymorphism.
What? Generics have nothing to do with polymorphism. They don't break polymorphism, and polymorphism does not provide the mechanism that generics provide.
> I don't think getting rid of primitives is
> realistic.
It is very realistic; it has been done successfully in several languages.
> What would you use to index
> arrays with? Objects?
You would index arrays with integers (objects).
> So arrays would
> inherently be hash maps? What kind of
> performance impact would that have?
No, an array would not be a hash map. A hash map allows dynamic insertions/deletions and stores by a hashing function, whereas an array is a continuous region of memory. Objects would present no performance impact, since the compiler could easily "convert" the object integer index into a primitive as necessary.
Although I am not entirely certain, I don't believe you are correct about this. Postgres did innovate a lot of features in the database world, particularly the notion of the "active database" (triggers, etc). Postgres also innovated some other things that have never appeared elsewhere (time travel).
I know that postgres has the ability for you to define your own types, but I am not certain about the extent of its object-relational capabilities.
Although PostgreSQL is vastly superior to MySQL, it is still nowhere near being on par with Oracle. Oracle has an incredible number of features that are lacking in PostgreSQL. A few of them are:
1. Hot Backups. This does NOT just mean a "consistent snapshot" as postgres provides; it implies a backup manager that can successively apply transactions from a redo log.
2. Asynchronous replication, parallel server, and hot standbys. You claim that postgres does replication however a search for 'replication' on the PostgreSQL mirrors yields no information.
3. Object-relational database features.
4. Extremely adequate documentation spanning ~30 non-overlapping books.
5. Materialized views, transaction savepoints, warehouse queries (cube, rollup), stored procedures in java...
These are just the heavily-used enterprise features; if I listed all the obscure features of Oracle, this post would be very long.
> If PostgreSQL could magically don an Oracular
> CIO-level reputation, the bottom half - or
> more - of the Oracle market would evapourate
> in a few short years.
Oracle Standard Edition is $300 per user. Most corporations would not want to "downgrade" to save $300, since their database is usually a rather criticial part of their operation.
For a webiste, however, you would have to buy an unlimited license ($15,000). For a small website, postgres is clearly a superior choice.
The PostgreSQL license is derived from the BSD license, since PostgreSQL was derived from a research project at Berkeley.
> 1. Documentation is piss-poor.
On this point I disagree completely. CVS has the best documentation of almost any open source project I've seen. Cederqvist wrote a significant book on the subject, which is open source and freely redistributed. Typing "info cvs" brings up documentation that is coherent, explanatory, cross-referenced, and organized.
Most open source projects have documentation that is a few pages of badly written english. Usually that documentation answers no questions and provides no information.
I'm curious to know exactly what your complaints are about the current cvs documentation.