-No multiple inheritance: There are cases where multiple inheritance can be nice, but for the most part it is a highly overrated. Most languages that DO implement multiple inheritance do it in such a way that it's a bad idea to use it regardless. For the most part, aggregation is actually much prettier than multiple inheritance.
- There tons of VMs out there which do not have the problems you describe for memory management. In particular, for real-time OS's this doesn't happen, and with Java's real-time extensions it's even easier to avoid this problem. Even the stock JDK 1.3 VM does most of it's GC in a background thread, and if that isn't good enough for you then you can enable incremental GC (and again, this does ad some latency, but if that's a problem, you should be using the real-time extensions). You mention incrememntal GC below (although you misunderstand how it works... there are still sweeps going on), so I don't know how you can complain.
- Having to call the finalize method of the base class makes a lot of sense. If you don't get this you obviously haven't done a lot of OO development. It's very consistent with the notion that the constructor for an object must call the constructor of it's super class.
A have to say I don't think you know what you are talking about.
First off, you are mixing up the notions of OO and "High-Level". I presume by "High-Level" you mean a "High-Level" of abstraction. It is quite possible to have an OO language which provides very little abstraction (you could take a subset of C++ and call it an OO language, and it's certainly not that high level).
"Garbage Collection" is probably not the right term to use either. What you're talking about here is automatic memory management. There is not necessarily overhead in automatic memory management, and certain techniques for automatic memory manage can reduce overhead substancially.
Good OO programming can actually significantly reduce the size of a program. Java has been used in embedded environments for this precise reason. By reusing code you save a lot of space.
Sure, assembler code can achieve essentially anything that is possible in software because it is a form of expressing the exact instructions you are sending to the processor. That being said, in the real world, you don't have an infinite amount of time to optimize your code. You have a fixed amount of time, and as a consequence your assembler programming team is usually going to get it's butt kicked. C compilers have been outperforming hand assembly for quite a while now, and Java is certainly capable of the same feat. It's just a matter of time.
Java's real overhead comes from the VM. There's a signifcant amount of overhead in that. Now, in some projects, the relative overhead of the VM is puny, and so Java proves to be an exceptionally efficient language. In others, the VM is 10x the size of what you'd expect the whole program to consume. There you are screwed.
For specific tasks, C (which is considered pretty low level by most) has been beaten by APL, Lisp, Self, Smalltalk, and yes... even Java. It just depends on how well the people writing the software for these different languages tuned it for specific operations. If you are working at a low enough level, you can do that for yourself, which is a nice advantage in some situations. Unfortunately, the price you pay the rest of the time consumes more than enough of your time that you'll never have a chance to do that optimization.
....but my example was written up in a proprietary document format. I no longer have a valid license for the software which created the document. As such, any attempts to make the document available to you would be a violation of the DCMA.;-)
Just allow me to assure you: corporations with big budgets do NOT make decisions based on technical merit. I still remember back in the IIS 1.0 days when one bank insisted that Windows NT had to be used to host this Java-based (on the server) web application because the VP of the division had, "a bad experience with Unix." No, he never specified which Unix, and no, IIS had zero support for Java at the time.
Your problems are reliability and performance of the threading mechanism? Well, you could use Kaffe and tweak it to suit your needs, but let's consider this in more detail for a second.
The thread context switch time is indeed a Linux-wide problem. The latest 2.4-testX series does have some patches which will let the pthreads guys get around this problem, but unless you want to build it yourself, you are going to have to wait at least another 6 months for those changes to be well tested and rolled out. That being said Linux still manages to achieve high scores on VolanoMarks, so perhaps your problem lies elsewhere.
As far as stability, goes, the Sun JDK 1.3 is fairly stable by my count. On average it's been more stable than the IBM one (although the IBM one is sooooo fast)! If you are encountering a bug, I'd suggest:
Reporting it to Sun's Bug Parade
Downloading the latest Blackdown release and seeing if it's been fixed.
Reporting the bug to the blackdown mailing list.
This is probably the easiest way to get a more stable VM.
Finally, if thread context-switch time is really that important to you, might I suggest that you've either got a flaw in your design or that Java is perhaps not the best solution for your problem. There are real-time extensions to Java, but without those, it's pretty hard to get decent performance guaruntees about those kinds of things for Java.
Are you suggesting that 5 years ago MCI and IBM weren't huge corporations? Does the PSINet of today somehow dwarf them? Please. Data services and telecommunications have been big business for quite some time, and they certainly were 5 years ago.
And costs, particular if they are severe, trump both. If technical innovations weren't already being employed on a regular basis by tier 1 NSPs the Internet would have died under it's own weight 5 years ago.
There is no way Bill Gates would write a letter like this, if for no other reason than the style of the prose. Then there's the whole notion of him sending out an e-mail this large about Linux to all microsoft employees. Yeah RIGHT!
The "Halloween" tradition is not something that exists at Microsoft either. "Halloween" was just when the documents were leaked, nothing else.
An interesting point. The good news is that the growth curve for log(n) is much flatter than Moore's law's exponential curve. Indeed, if n is growing exponentially, that means you have a linear growth curve.
While memory speeds haven't been improving as per Moore's law, they have been improving. There's an interesting article on some of the techniques to help with the problem at:
http://www.acm.org/crossroads/xrds5-3/pmgap.html
I think in the 6 years that these growth numbers are talking about we've gone from 33MHz 32-bit memory buses (yes, pentiums already had faster buses, but what I'm describing were pretty common) to the point where we now have 133MHz 128-bit (and in some cases even wider) double pump buses pushing data into increasingly faster and larger cache memory regions. Then you throw in ideas like compression and you can imagine that memory speed has been improving well enough to keep up with this growth.
I'm exactly thinking tier 1 NSPs will role out a different protocol. It could very much happen VERY quickly if for some reason BGP was imposing a significant cost/performance overhead as opposed to an alternative solution. The main reason why changing from BGP is crazy right now is that BGP meets their needs and it's in place. Once that's no longer true change will take place quite rapidly.
This will not necessarily happen. It's quite possible that IPv6 traffic and IPv4 traffic will be split and passed off to different routers. This would provide incentive to use IPv6 as it would presumably be faster. Additionaly, even if Dual-IP-layer routing is necessary, one would hope that once IPv6 arrived, the IPv4 routing tables would stop growing so aggressively, as new IP's become IPv4 addresses. Should that prove to be the case, things will be easier.
P.S.: I presume you mean IPv4 rather than IPv5.;-)
Let's go through a number of things that came up here:
BGP isn't working. Well, fortunately, there are a lot of other protocols out there to choose from. When it becomes too costly for everyone to have routers using BGP, people will negotiate the use of other protocols.
Routers will need "gigabits" of memory within two years. Well, that sounds really scary, but of course a "gigabit" is roughly 128MB. That is a lot of memory for a router, but right now that'll cost you at most $150. In two years time you'd like to think it'd be a lot less. Either way, it's a tiny portion of the cost of a router. I think we'll survive that.
In 6 years we went from 10,000 to 100,000 entries. That is some pretty serious growth, but it is not nearly as scary when you consider that Moore's law suggests that processing power has improved 2^4 = 16 times in the same time frame. So, in other words, CPU speeds at least are easily out pacing the growth of routing tables. I don't know how this plays out for memory, but I seem to recall that 6 years ago 16MB of memory was over $1000 and now 256MB of RAM for a laptop is $400. Bottom line: it's easy to make computing growth numbers look scary, because computing is growing at a scary rate. You just have to remember that both the capability and need side of the equation are growing at an insane pace.
Of course IPv6 changes all this. Part of the reason the routing tables are growing so much is because IPv4 does not make routing tables very efficient. Chalk this up as one more reason to use IPv6. Given that IPv6 is available today, I think the relevant parties will make the switch when it starts saving them lots of $$'s.
When the P6 was released, it was the fastest processor available in industry standard benchmarks (SPEC, including Alpha)
Woo boy... hold on there. First of, the "P6" is not a processor, but a processor core. It was also the code name for the CPU later to be marketed as the "Pentium Pro". The Pentium Pro was an impressive chip, and for some types of operations, it was increadibly fast. However, it did not beat everything else out there with SPEC benchmarks.
For starters, SPEC is not a single benchmark, rather a consortium that comes up with benchmarks, the most well recognized being their CPU benchmarks (colloquially refered to as SPEC benchmarks). These benchmarks however, do not exclusively test a CPU, but rather a system as a whole, although they are designed to make the CPU the limiting factor (nonetheless using bucket loads of RAM, fast disk controllers, and a huge external memory cache can have wonderful impacts on SPEC benchmarks). Typically these benchmarks have been divided into those that stress the integer unit (SpecInt) and those that stress the floating point unit (SpecFP). The Pentium Pro was the first x86 CPU to post respectable SpecFP benchmarks, but it still got it's butt kicked all over the place compared to it's RISC competition.
Even on the SpecInt benchmark, the earliest PPro benchmarks I could find on Spec's website show that while the PPro put in some respectible numbers, it was far from being the king of the SpecInt benchmark.
The PPro was a breakthrough in terms of it's price/performance. This was largely due to economies of scale rather than design genius.
Despite all that, I think the PPro design was very impressive. It was probably the strongest evidence at the time that CISC could hold it's own against RISC competition, something the pundits had been suggesting wasn't going to happen.
The filesystem is a fixed-size file, thus unnecesssarily eating diskspace when it's not filled and not being extendable as soon as it is full.
I guess it depends on how you're using it, but I'd loopback on an actual partition (rather than a file), thereby encrypting the entire partition. This seems like a safe approach to me.
Yes, you're wasting space, but if you normally use a partition anyway it's fine. The other advantage is, of course, the fact that there can't be any size-based observations about the encrypted data.
BTW; also points up the lack of connection between porn and rape.
Would that that were true. Unfortunately, their is always the issue about the rate of rapes being reported. It's been argued that countries with high levels of porn tend to have cultural values which reduce the chance of rape being reported. I'm not saying they're correct, but unfortunately you can't judge rape incidence based on the indicence of reported rape.
Micron actually does an excellent job of building chipsets. They bought a company that did motherboard work for exactly this reason (I can't remember who, but it was someone who specialized in high end stuff). The Samurai chipset was the result of this, and it was one of the early adopters of 64-bit PCI. Indeed, this would have been THE high-performance chipset if Intel hadn't come out with AGP at the same time.
Trust me, these guys are very good at what they do.
Actually, if you read through that data your original statement doesn't bear out. You said:
An increase in wealth equals a decrease in population growth rate.
Which is quite different from what these graphs demonstrate. Instead, what they suggest is that at a certain point of development, death rates drop off. After a time, societies react to that and birth rates drop off proportionately. Net result: growth rates stabalize in the long run.
The last paper in particular breaks the chart in to 4 stages, and clearly suggests that the transition from stage 1 to stage 2 results in a pretty dramatic growth rate. So, in that case, an increase in wealth equals a huge increase in growth.
A better way to describe this theory is that the transition to modern times destabilizes whatever societal balances exist between birth and death, resulting in a huge rate of growth, which is then inevitably corrected by society.
Oh, and most of the studies are talking about how "developed" a society is as opposed to how wealthy. The last study correlates the two, although only with a grand brush. There is certainly the possibility of becoming developed without becoming wealthy or vice-versa.
When you look at it like that (where Stage 1 & Stage 4 have similar growth rates) you can't be quite so sure where some societies will be in the long run. Some societies had impressive growth rates before the 18th century when this whole process started. Presumably, they will return to this level of growth at some point.
What is the problem with Entity beans? Those are pretty much fundamental to J2EE. I can understand your concerns about container-managed persistence, but I find that there are a number of containers out there that do an OK job for a lot of applications.
Yeah, but in the absense of conclusive evidence (i.e. either argument can be supported by facts) doesn't it make sense to suggest there is little or no correlation? That actually it's entirely seperate factors (which may have a similar utopian effect as you're describing) which are influencing population growth, or at the very least which are much more significant?
To date, all the examples of large nations who's growth rate has slowed as they got richer are all Western nations, and reflect cultural attitudes of those nations. Indeed, if you look outside of Western culture, wealth seems to increase growth rates more often than not.
But let's take your argument of looking at the big picture (which is what a statistician would say). The world as a whole is getting wealthier every year, and yet as a whole, it's population is continuing to grow equally impressively. Furthermore, overall population growth rates seem not to have been substancially impacted by various slow downs in the world economy.
Even if you limit your statement to Western nations history doesn't match your sentiment. In the United States, during the '50s (prior to now some of the best economic times in the country's history) we had the baby boom.
>They're also becoming richer. An increase in
>wealth equals a decrease in population growth
>rate. This is common knowlege to any high school
>social sciences teacher. This is the glimmer of
>the natural mathematical push towards the steady
>state. I don't claim that as any sort of proof,
Such statements are based on GROSS assumptions about the social fabric of a country. Kuwait's population growth exceeds that of Kazakhstan, and I think Saudi Arabia has a bigger growth rate than either.
So while a social sciences high school teacher might say this, an expert anthropologist would disagree.
Slashdot Mirror
-No multiple inheritance: There are cases where multiple inheritance can be nice, but for the most part it is a highly overrated. Most languages that DO implement multiple inheritance do it in such a way that it's a bad idea to use it regardless. For the most part, aggregation is actually much prettier than multiple inheritance.
- There tons of VMs out there which do not have the problems you describe for memory management. In particular, for real-time OS's this doesn't happen, and with Java's real-time extensions it's even easier to avoid this problem. Even the stock JDK 1.3 VM does most of it's GC in a background thread, and if that isn't good enough for you then you can enable incremental GC (and again, this does ad some latency, but if that's a problem, you should be using the real-time extensions). You mention incrememntal GC below (although you misunderstand how it works... there are still sweeps going on), so I don't know how you can complain.
- Having to call the finalize method of the base class makes a lot of sense. If you don't get this you obviously haven't done a lot of OO development. It's very consistent with the notion that the constructor for an object must call the constructor of it's super class.
A have to say I don't think you know what you are talking about.
First off, you are mixing up the notions of OO and "High-Level". I presume by "High-Level" you mean a "High-Level" of abstraction. It is quite possible to have an OO language which provides very little abstraction (you could take a subset of C++ and call it an OO language, and it's certainly not that high level).
"Garbage Collection" is probably not the right term to use either. What you're talking about here is automatic memory management. There is not necessarily overhead in automatic memory management, and certain techniques for automatic memory manage can reduce overhead substancially.
Good OO programming can actually significantly reduce the size of a program. Java has been used in embedded environments for this precise reason. By reusing code you save a lot of space.
Sure, assembler code can achieve essentially anything that is possible in software because it is a form of expressing the exact instructions you are sending to the processor. That being said, in the real world, you don't have an infinite amount of time to optimize your code. You have a fixed amount of time, and as a consequence your assembler programming team is usually going to get it's butt kicked. C compilers have been outperforming hand assembly for quite a while now, and Java is certainly capable of the same feat. It's just a matter of time.
Java's real overhead comes from the VM. There's a signifcant amount of overhead in that. Now, in some projects, the relative overhead of the VM is puny, and so Java proves to be an exceptionally efficient language. In others, the VM is 10x the size of what you'd expect the whole program to consume. There you are screwed.
For specific tasks, C (which is considered pretty low level by most) has been beaten by APL, Lisp, Self, Smalltalk, and yes... even Java. It just depends on how well the people writing the software for these different languages tuned it for specific operations. If you are working at a low enough level, you can do that for yourself, which is a nice advantage in some situations. Unfortunately, the price you pay the rest of the time consumes more than enough of your time that you'll never have a chance to do that optimization.
That of course is DMCA, not DCMA.
....but my example was written up in a proprietary document format. I no longer have a valid license for the software which created the document. As such, any attempts to make the document available to you would be a violation of the DCMA. ;-)
Just allow me to assure you: corporations with big budgets do NOT make decisions based on technical merit. I still remember back in the IIS 1.0 days when one bank insisted that Windows NT had to be used to host this Java-based (on the server) web application because the VP of the division had, "a bad experience with Unix." No, he never specified which Unix, and no, IIS had zero support for Java at the time.
Your problems are reliability and performance of the threading mechanism? Well, you could use Kaffe and tweak it to suit your needs, but let's consider this in more detail for a second.
The thread context switch time is indeed a Linux-wide problem. The latest 2.4-testX series does have some patches which will let the pthreads guys get around this problem, but unless you want to build it yourself, you are going to have to wait at least another 6 months for those changes to be well tested and rolled out. That being said Linux still manages to achieve high scores on VolanoMarks, so perhaps your problem lies elsewhere.
As far as stability, goes, the Sun JDK 1.3 is fairly stable by my count. On average it's been more stable than the IBM one (although the IBM one is sooooo fast)! If you are encountering a bug, I'd suggest:
This is probably the easiest way to get a more stable VM.
Finally, if thread context-switch time is really that important to you, might I suggest that you've either got a flaw in your design or that Java is perhaps not the best solution for your problem. There are real-time extensions to Java, but without those, it's pretty hard to get decent performance guaruntees about those kinds of things for Java.
Are you suggesting that 5 years ago MCI and IBM weren't huge corporations? Does the PSINet of today somehow dwarf them? Please. Data services and telecommunications have been big business for quite some time, and they certainly were 5 years ago.
And costs, particular if they are severe, trump both. If technical innovations weren't already being employed on a regular basis by tier 1 NSPs the Internet would have died under it's own weight 5 years ago.
There is no way Bill Gates would write a letter like this, if for no other reason than the style of the prose. Then there's the whole notion of him sending out an e-mail this large about Linux to all microsoft employees. Yeah RIGHT!
The "Halloween" tradition is not something that exists at Microsoft either. "Halloween" was just when the documents were leaked, nothing else.
An interesting point. The good news is that the growth curve for log(n) is much flatter than Moore's law's exponential curve. Indeed, if n is growing exponentially, that means you have a linear growth curve.
l
While memory speeds haven't been improving as per Moore's law, they have been improving. There's an interesting article on some of the techniques to help with the problem at:
http://www.acm.org/crossroads/xrds5-3/pmgap.htm
I think in the 6 years that these growth numbers are talking about we've gone from 33MHz 32-bit memory buses (yes, pentiums already had faster buses, but what I'm describing were pretty common) to the point where we now have 133MHz 128-bit (and in some cases even wider) double pump buses pushing data into increasingly faster and larger cache memory regions. Then you throw in ideas like compression and you can imagine that memory speed has been improving well enough to keep up with this growth.
I'm exactly thinking tier 1 NSPs will role out a different protocol. It could very much happen VERY quickly if for some reason BGP was imposing a significant cost/performance overhead as opposed to an alternative solution. The main reason why changing from BGP is crazy right now is that BGP meets their needs and it's in place. Once that's no longer true change will take place quite rapidly.
This will not necessarily happen. It's quite possible that IPv6 traffic and IPv4 traffic will be split and passed off to different routers. This would provide incentive to use IPv6 as it would presumably be faster. Additionaly, even if Dual-IP-layer routing is necessary, one would hope that once IPv6 arrived, the IPv4 routing tables would stop growing so aggressively, as new IP's become IPv4 addresses. Should that prove to be the case, things will be easier.
;-)
P.S.: I presume you mean IPv4 rather than IPv5.
Let's go through a number of things that came up here:
Perhaps you might want to give a clearer explanation of the differences? ;-)
Woo boy... hold on there. First of, the "P6" is not a processor, but a processor core. It was also the code name for the CPU later to be marketed as the "Pentium Pro". The Pentium Pro was an impressive chip, and for some types of operations, it was increadibly fast. However, it did not beat everything else out there with SPEC benchmarks.
For starters, SPEC is not a single benchmark, rather a consortium that comes up with benchmarks, the most well recognized being their CPU benchmarks (colloquially refered to as SPEC benchmarks). These benchmarks however, do not exclusively test a CPU, but rather a system as a whole, although they are designed to make the CPU the limiting factor (nonetheless using bucket loads of RAM, fast disk controllers, and a huge external memory cache can have wonderful impacts on SPEC benchmarks). Typically these benchmarks have been divided into those that stress the integer unit (SpecInt) and those that stress the floating point unit (SpecFP). The Pentium Pro was the first x86 CPU to post respectable SpecFP benchmarks, but it still got it's butt kicked all over the place compared to it's RISC competition.
Even on the SpecInt benchmark, the earliest PPro benchmarks I could find on Spec's website show that while the PPro put in some respectible numbers, it was far from being the king of the SpecInt benchmark.
The PPro was a breakthrough in terms of it's price/performance. This was largely due to economies of scale rather than design genius.
Despite all that, I think the PPro design was very impressive. It was probably the strongest evidence at the time that CISC could hold it's own against RISC competition, something the pundits had been suggesting wasn't going to happen.
I guess it depends on how you're using it, but I'd loopback on an actual partition (rather than a file), thereby encrypting the entire partition. This seems like a safe approach to me.
Yes, you're wasting space, but if you normally use a partition anyway it's fine. The other advantage is, of course, the fact that there can't be any size-based observations about the encrypted data.
Would that that were true. Unfortunately, their is always the issue about the rate of rapes being reported. It's been argued that countries with high levels of porn tend to have cultural values which reduce the chance of rape being reported. I'm not saying they're correct, but unfortunately you can't judge rape incidence based on the indicence of reported rape.
Micron actually does an excellent job of building chipsets. They bought a company that did motherboard work for exactly this reason (I can't remember who, but it was someone who specialized in high end stuff). The Samurai chipset was the result of this, and it was one of the early adopters of 64-bit PCI. Indeed, this would have been THE high-performance chipset if Intel hadn't come out with AGP at the same time.
Trust me, these guys are very good at what they do.
Actually, if you read through that data your original statement doesn't bear out. You said:
An increase in wealth equals a decrease in population growth rate.
Which is quite different from what these graphs demonstrate. Instead, what they suggest is that at a certain point of development, death rates drop off. After a time, societies react to that and birth rates drop off proportionately. Net result: growth rates stabalize in the long run.
The last paper in particular breaks the chart in to 4 stages, and clearly suggests that the transition from stage 1 to stage 2 results in a pretty dramatic growth rate. So, in that case, an increase in wealth equals a huge increase in growth.
A better way to describe this theory is that the transition to modern times destabilizes whatever societal balances exist between birth and death, resulting in a huge rate of growth, which is then inevitably corrected by society.
Oh, and most of the studies are talking about how "developed" a society is as opposed to how wealthy. The last study correlates the two, although only with a grand brush. There is certainly the possibility of becoming developed without becoming wealthy or vice-versa.
When you look at it like that (where Stage 1 & Stage 4 have similar growth rates) you can't be quite so sure where some societies will be in the long run. Some societies had impressive growth rates before the 18th century when this whole process started. Presumably, they will return to this level of growth at some point.
What is the problem with Entity beans? Those are pretty much fundamental to J2EE. I can understand your concerns about container-managed persistence, but I find that there are a number of containers out there that do an OK job for a lot of applications.
Yeah, but in the absense of conclusive evidence (i.e. either argument can be supported by facts) doesn't it make sense to suggest there is little or no correlation? That actually it's entirely seperate factors (which may have a similar utopian effect as you're describing) which are influencing population growth, or at the very least which are much more significant?
To date, all the examples of large nations who's growth rate has slowed as they got richer are all Western nations, and reflect cultural attitudes of those nations. Indeed, if you look outside of Western culture, wealth seems to increase growth rates more often than not.
But let's take your argument of looking at the big picture (which is what a statistician would say). The world as a whole is getting wealthier every year, and yet as a whole, it's population is continuing to grow equally impressively. Furthermore, overall population growth rates seem not to have been substancially impacted by various slow downs in the world economy.
Even if you limit your statement to Western nations history doesn't match your sentiment. In the United States, during the '50s (prior to now some of the best economic times in the country's history) we had the baby boom.
>They're also becoming richer. An increase in
>wealth equals a decrease in population growth
>rate. This is common knowlege to any high school
>social sciences teacher. This is the glimmer of
>the natural mathematical push towards the steady
>state. I don't claim that as any sort of proof,
Such statements are based on GROSS assumptions about the social fabric of a country. Kuwait's population growth exceeds that of Kazakhstan, and I think Saudi Arabia has a bigger growth rate than either.
So while a social sciences high school teacher might say this, an expert anthropologist would disagree.
Checked in more closely on this map of the RTP area. There is a "Wake" county, but if you will notice the larger share of RTP is in Durham county.
Now to check out what the local police department says.
Oh my GOD! This poster is actually right! People, please moderate this up!
I just went to this site. Notice the "Select by County" option. There's a Wilkes County, and a Wilson County, but no "Wise County".