I don't know if Sun will mind much though, free software implementations of Java is only healthy for the platform, and since Sun derives no profits from the platform itself it is a purely good thing.
One might even say that making their implementation free would be worse for Java since it would be more likely to end up a monoculture that way.
Unfortuately things can happen like a GC cycle at a bad time that can cause annoying slowdowns at the worst moment.
Indeed a problem for garbage collectors, luckily Java ships with several different algorithms. The one used by default (full halt for a step in generational GC) has the best throughput.
If you are more worried about short pauses you have two other alternatives however. The concurrent low pause pause collector will halt the application threads only in some phases of the collection, it is activated with the -XX:+UseConcMarkSweepGC flag (or system property). It does work in a different thread, so it is a good bet if you have multiple processors especially. The other option is the incremenetal collector, -Xincgc, which will do minor collections in parts with application threads getting to run between the steps (causing the pause to be spread out).
Another notable option in these multicore days is -XX:+UseParallelGC, which will launch several GC threads and do some of the work in parallel.
Overall there is a lot of opportunity to tune the Java garbage collector, google about on it a bit, it has been shown quite feasible to make nice interactive experience with Java (Jake2 anyone?). If even better guarantees are needed however it is probably best to look at one of the realtime JVM's. There are a variety available.
The 1024 bit factoring table is physically impossible in this solar system since there are no means to store that much data, plus that it is impossible to actually enumerate all numbers [1, 2^1024] even if we were able to use all the energy output by the sun in the remainder of its lifetime to do it.
So I don't find the comment terribly valid, even though one could argue that it is still possible by some hypothetical future technology it is still not the best argument I have heard why a printer that has actually been built and tested is uninteresting.
It it not even about practibility, these things are huge enough to come down to theorethical tractability (though some people stubbornly refuse to tie the theory of computability to physics it is really a good measurement to consider the limits imposed by quantum mechanics).
In terms of engineering this ain't nothing new. You can do multiplication in O(1) space and O(n^2) time or O(1) time and O(n^2) space [well it's actually O(lg N) time... but who's counting].
What? How is this in any way relevant to making printers? Or are you really arguing that we can in general do anything arbitrarily fast with a trade-off in another area?
Skipping the vector units makes the Cell look quite tame in perfomance, as I said the primary core is an old-style in-order design, while it is clocked quite high it will still have a hard time trying match a G5 in performance. Things that appear as downgrades to the customers are bad things.
My guess on the AMD/Intel issue is that the Pentium M was the deciding factor, it really is a very sweet chip in the notebook market (which is large and high-margin). It is hard to guess what it happening there though since Apple has no doubt seen more of Intels roadmaps than what is publicly available. At any rate, the switch is the heavy part, no reason to believe that we wont see AMD machines if AMD continues to put out the nice chips they have so far. After all Apple has done similar things with NVidia and ATI, picking differently for different generations of their machines.
The problem with that moral is that compiler technology is nowhere near where it needs to be. Doing VLIW and other explicitly parallel architectures has been a research darling for many years, it just so happens that compiler technology fails to really make it work as things stand.
Compilers do manage to do decent jobs in some cases, especially with languages that are easier to do semantic analysis over than C/C++, but while it is interesting research it is not a practical way to go. The reality is that C/C++ is prevalent, and highly detuned code is abundant. This also fails to address the problem of migrating between versions of the processor, while recompiling everything every time is a way to go it is not terribly practical (and when every new processor will fail to measure up to the old in the users old apps the user will not be happy).
It is a bit odd that you bring up the Itanium since it is the best argument for this stance, there has not been any lack of effort in the compiler technology for the Itanium, the compilers are real marvels leveraging the very best the research has to offer. The silicon itself is very powerful, if you manage to actually fill all the instruction slots the thing will really fly. Unfortunately they never do, they get 50% fills and such, and the problem is that a modern sophisticated OoO processor will do an equally good job extracting parallelity on the fly while offering more flexibility.
A large part of the problem, and the reason why multithreaded models are becoming pervasive, is that OoO processors actually extract very close to the maximum in instruction level parallelism even with near-infinite window-sizes (I recommend the paper at http://citeseer.ist.psu.edu/145067.html), so automatic vectorization of ILP is not a field to pin much hope on.
My final note is that; While having sophisticated issue logic is fairly complex, the chip real estate is not that large, and the gains to be made are huge. The Cell has a weak primary processor, mostly meant to be an organizing hub for the vector operations, if you don't write vectorized code you are screwed (unless compiler technology does something amazing soon).
While this is a nice thing to say it is not realistic today, Intel already tried with the Itanium to push the handling of instruction level parallelism to the compiler, with poor results. This has been a meme for easily 20 years (VLIW has been a research darling for a long time) but compiler technology has just not measured up to the expectations.
While it might be the way of the future, it is very much a thing of the future, not the present.
Expect to see lots of carefully hand-tuned code for the Cell to make it behave.
In this thread I have already seen several posts talking about the worthlessness of the ill-designed x86 and the wonders of the simple Cell. The problem is that while the x86 instruction set is old and very tacky the internals of the processors has evolved to be best-of-breed modern chips, lots of execution units with excellent out-of-order performance and branch-prediction, very high clockrates with nice IPC.
The Cell also is simple, but in a way that that inflates the gflop rating at the cost of programmer time.
Multicore, requiring the programmers to extract explicit parallelity (granted, this is coming everywhere, but really, the fewer better-performing cores there are the easier they are to utilise well).
A whole pile of vector units (it is very hard to fill even one or two vector units well, this will be a huge time-sink for any project trying to utilise it even half-way well).
An in-order primary CPU core, what is this, the eighties?! And if you think this will be like stepping back to how it was with in-order cores a decade or two ago, think again, memory latencies are higher, pipelines are deeper, you'd better pray that your compiler gets lucky to get any real performance out of the primary core (or many sleepness nights hand-optimizing it).
Hand-managed memory hierarchy?! This is not even a throwback to the eighties, this is a whole new level of inconvenience for the programmer. Where all normal CPU's carefully handle the memory hierarchy for you, in the Cell it is suddenly up to the software to handle where and when and why memory is in the "cache" of the vector elements.
By comparison the modern x86 is a dream to program for, just note how two fairly radically different cpu's (Athlon64 and the P4) handle the same code very nicely without any big performance issues. Compare this to the Cell, where all the explicitness will make sure that any binary you write for the Cell today will run like crap on the next version.
The point here is that Apple could absolutely not have switched to the Cell, it is inconvenient now and hopeless to upgrade without having to rewrite a ton of assembler and recompile everything for the new explicit requirements.
The Cell is the thing for number crunching and pro applications where they are willing to spend the time optimizing for every single CPU, but for normal developers it is a step back.
There are real problems with the way IBM is going with the PPC also however. They are going with much simpler in-order cores plus a whole bunch of vector units. The problem with this is that while you can get great performance with few transistors with code specially tuned for the chip you will get abysmal performance if the code is not tuned.
Sure we have lived with in-order cores before (out-of-order was introduced to the PC with the Pentium Pro), but it is troublesome, we are back to the compiler having to do the heavy lifting trying to put together the ideal instruction stream. It is actually a lot worse than it seems when I compare it with the original pentium, with its shallow pipeline and the relativly speaking lower memory latency of those days you could get away with a lot more without trashing performance.
Even if Apple through some magic manages to generate decent code for the in-order primary core (and it is not unlikely that they'd have to dump GCC since lots of hard-to-merge work would have to be done, and then they would lose the advantage of having a freely redistributable compiler) they will still be stumped on the vector units. Sure some of the heavier apps manage to make good use of Altivec, but that is a lot easier than trying to keep 8-16 vector units filled at the same time. Basicly only scientific and various extremely expensive pro applications would ever manage to invest the effort needed to actually manage to tap much of the power of the vector units (part because vectorization is hard, but also importantly because there are so many units to fill).
This all adds up to the Cell (and IBM's new in-order cores without the vector units) being quite unsuitable for any market where the applications are not written very specifically targeting the chip. It works for consoles since development is hardware-specific there, but putting out a computer with the Cell and expecting it to work out on peoples desktops is not in any way a good idea.
Volume problems, AMD is not really known for being able to deliver chips reliably because of lower volume and limited production facilities.
Pentium M. Even though the workstation chips are a bit in AMD's favor, the notebooks are more important (more popular and higher margin) and Intel is clearly ahead in this area (the Pentium M is really the sweetest x86 in its market in years).
It is true that Athlon64 typically does better than the Pentium 4 in benchmarks. On the other hand a large part of the problem is that the Pentium 4 is more sensitive to how the code is structured, and with Apple's complete control over the hardware compiler, and OS/support libraries they can make the P4 feel at home. This makes any disadvantage of the P4 much less significant (and no matter what the fanboys say, the difference is not that dramatic to start with, compare to earlier CPU wars and P4 vs. Athlon64 seems quite tame).
Who knows what Intel's and AMD's roadmaps contains? We no doubt have far less information than Apple has seen during the negotiations.
I don't know about the rest of you, but this whole going extinct thing is what I am worried about, the earth continuing along after we are gone or not is a much lesser worry.
In the same vein, if a climate change that would kill us is "natural" I really don't care for natural. Better learn and figure out how to get a more unnatural but more friendly result if we at all can.
If a religion posits that "number theory is only a theory", and comes up with some religious alternative, then should math classes give them equal time?
Please don't spread more confusion about the word "theory". The "theory of evolution" really is a theory in the sense that it is a falsifiable conjecture based on a large body of empirical observations. "Number theory" is of course not, it is there just a word used to refer to an axiomatic system in mathematics, and is as such necessarily "true" (though it is in itself unconnected with any physical objects and incomplete).
I am sure you know this and intended the fomulation, but too many people seem to have a somewhat poor grasp of how empirical and formal sciences relate so I just want to clarify.
Good work on the math there. Not that your opinion is of any interest to anyone anywhere either. Why is it that people feel that saying "this is uninteresting" is interesting for anyone else?
They also suck since it is near-impossible to see which button has keyboard focus, instead of the regular dotted rectangle used in the rest of Windows they have a slight lighter tint when active. Real easy to tell. I end up having to switch focus a few times before pressing enter every time just to be sure that the button I want is the active one.
Environments defaulting to 64-bit ints are exceedingly rare, and it is hardly suprising. Since all applications expect 32 bit ints (or possibly smaller in a very small number of cases) there is nothing to be gained from upping the size of the basic int to 64 bits except a mean performance hit.
To put it this way, changing int's would be troublesome, be a performance hit and not give any advantages (since anyone needing a 64 bit word knows where to look already). Changing the size of the regular long int would maybe be more sensible since it is a bit useless to have it be defined as the same size as int as it typically is today, but really, it is not useful in any way other than to make the type hierarchy slightly nicer, and that is hardly worth the trouble.
All W3C standards are heavily flawed. One can in general say this much about the situation, if something (the WWW) has been around for >15 years, and despite this:
- The user experience is only so-so.
- The standards are so numerous that it is hard to even have a general idea where all fit into the big picture.
- Writing a reader for it is such a huge undertaking that not even the largest and most successful businesses manage to pull it off well then something has gone very wrong.
then something is wrong.
The WWW should have been able to stabilize at some level years ago, making it possible to actually make a browser with a reasonable amount of effort. The underlying problem is not that hard, it is just a continuos pie-in-the-sky standardization effort ripping everything invented at any point apart in the next revision since they have decided that there are some better way to do it.
People have at this point come to accept it as the way things should work (being worried when there is no new standard for a year or two), but this is really a hopeless situation. If we had actually reached any level of comprehensiveness as far as web-based applications were concerned it would be less to think about, but the web is still in a primitive state.
Consider this coders and software designers:
- Make a presentation format that separates content from layout.
- Allow textual information with embedded images and external plugins/objects.
- Include some basic scripting, some basic widgets (buttons, textfields, drop-down boxes).
- See to that it is decently easy to screen-scrape, use with screen-readers and is resolution independent (may be done by automatic switching of layouting information).
Does anyone really feel that this has to be so complex that one can't complete it in under 15 years and one can't make it simple enough to actually make it possible for a hobbyist to implement a reader for? Sure the W3C has standards for a lot more, but that is part of the problem, the core is too huge. If one had a simple core it would have been easy to throw in MathML later and get people to pick it up, but since it is hard to in any sense even finish the core who is going to have time to make MathML work?
Since it is based on the whole-system simulator Simics -- Yes, it does assume that the app runs in isolation, since all external stuff is just simics simulations.
Except Intel will have dual core as well, and unsuprisingly they will have two cores with hyperthreading. Hyperthreading is by no means a hack, it is a very sensible performance enhancement that has been waiting in the wings ever since processors started having the current grab-bag of mixed execution units.
Don't start with "Intel dual core is just a hack" now, while it is true that AMD's approach is more cleanly executed it is far from obvious that it will yield any significant advantages over Intels.
The by now classic Slashdot statement "Intel has just put two P4's on one die with some wires in between" is quite silly, since that is what multicore is. AMD just happens to have more wires:)
How on earth do people continue to refuse to understand how this works?
IE is tied to the OS in the sense of the widget toolkit and the user experience. It is used in a variety of places to provide rich formatted content. It does not run in kernel-space and it is not required for the kernel to function. It is impossible to separate IE from windows since the widget is much too commonly used both by Microsoft and third party applications.
So lets do this again: The OS is not the kernel, the OS includes a huge amount of user-interacting code. This UI code makes use of IE in many ways. Removing IE would require tons of software being rewritten, not because it is directly a "core" feature of Windows, but rather because of proper software reuse going on in a lot of Windows software.
Must say that it is very nice to see Solaris up there in the top in the tests that it was featured in. Seems Sun was not joking around when they claimed that Solaris 10 would be greatly improved on x86. As is often said around here; More choice is good.
Worldforge has not been an argument for open-source game development since 1999. It is at this point rather a shining example of how dysfunctional the typical (large-scale) OSS game project is.
It has been well-documented and well-known for ages how to do PNG alpha channels in IE. The stereotypical slashdot whine is about it not being done automatically with just the standard tag (not a huge complaint for the ambitious, the extra piece of code needed to make IE work with it does not interfere with other browsers that worked already).
Slashdot Mirror
One might even say that making their implementation free would be worse for Java since it would be more likely to end up a monoculture that way.
Indeed a problem for garbage collectors, luckily Java ships with several different algorithms. The one used by default (full halt for a step in generational GC) has the best throughput.
If you are more worried about short pauses you have two other alternatives however. The concurrent low pause pause collector will halt the application threads only in some phases of the collection, it is activated with the -XX:+UseConcMarkSweepGC flag (or system property). It does work in a different thread, so it is a good bet if you have multiple processors especially. The other option is the incremenetal collector, -Xincgc, which will do minor collections in parts with application threads getting to run between the steps (causing the pause to be spread out).
Another notable option in these multicore days is -XX:+UseParallelGC, which will launch several GC threads and do some of the work in parallel.
Overall there is a lot of opportunity to tune the Java garbage collector, google about on it a bit, it has been shown quite feasible to make nice interactive experience with Java (Jake2 anyone?). If even better guarantees are needed however it is probably best to look at one of the realtime JVM's. There are a variety available.
Right right, cause god knows there are tons of great open source video streaming solutions out there with broad client support.
So I don't find the comment terribly valid, even though one could argue that it is still possible by some hypothetical future technology it is still not the best argument I have heard why a printer that has actually been built and tested is uninteresting.
It it not even about practibility, these things are huge enough to come down to theorethical tractability (though some people stubbornly refuse to tie the theory of computability to physics it is really a good measurement to consider the limits imposed by quantum mechanics).
What? How is this in any way relevant to making printers? Or are you really arguing that we can in general do anything arbitrarily fast with a trade-off in another area?
My guess on the AMD/Intel issue is that the Pentium M was the deciding factor, it really is a very sweet chip in the notebook market (which is large and high-margin). It is hard to guess what it happening there though since Apple has no doubt seen more of Intels roadmaps than what is publicly available. At any rate, the switch is the heavy part, no reason to believe that we wont see AMD machines if AMD continues to put out the nice chips they have so far. After all Apple has done similar things with NVidia and ATI, picking differently for different generations of their machines.
I post too much on this topic.
Compilers do manage to do decent jobs in some cases, especially with languages that are easier to do semantic analysis over than C/C++, but while it is interesting research it is not a practical way to go. The reality is that C/C++ is prevalent, and highly detuned code is abundant. This also fails to address the problem of migrating between versions of the processor, while recompiling everything every time is a way to go it is not terribly practical (and when every new processor will fail to measure up to the old in the users old apps the user will not be happy).
It is a bit odd that you bring up the Itanium since it is the best argument for this stance, there has not been any lack of effort in the compiler technology for the Itanium, the compilers are real marvels leveraging the very best the research has to offer. The silicon itself is very powerful, if you manage to actually fill all the instruction slots the thing will really fly. Unfortunately they never do, they get 50% fills and such, and the problem is that a modern sophisticated OoO processor will do an equally good job extracting parallelity on the fly while offering more flexibility.
A large part of the problem, and the reason why multithreaded models are becoming pervasive, is that OoO processors actually extract very close to the maximum in instruction level parallelism even with near-infinite window-sizes (I recommend the paper at http://citeseer.ist.psu.edu/145067.html), so automatic vectorization of ILP is not a field to pin much hope on.
My final note is that; While having sophisticated issue logic is fairly complex, the chip real estate is not that large, and the gains to be made are huge. The Cell has a weak primary processor, mostly meant to be an organizing hub for the vector operations, if you don't write vectorized code you are screwed (unless compiler technology does something amazing soon).
While it might be the way of the future, it is very much a thing of the future, not the present.
Expect to see lots of carefully hand-tuned code for the Cell to make it behave.
The Cell also is simple, but in a way that that inflates the gflop rating at the cost of programmer time.
By comparison the modern x86 is a dream to program for, just note how two fairly radically different cpu's (Athlon64 and the P4) handle the same code very nicely without any big performance issues. Compare this to the Cell, where all the explicitness will make sure that any binary you write for the Cell today will run like crap on the next version.
The point here is that Apple could absolutely not have switched to the Cell, it is inconvenient now and hopeless to upgrade without having to rewrite a ton of assembler and recompile everything for the new explicit requirements.
The Cell is the thing for number crunching and pro applications where they are willing to spend the time optimizing for every single CPU, but for normal developers it is a step back.
Sure we have lived with in-order cores before (out-of-order was introduced to the PC with the Pentium Pro), but it is troublesome, we are back to the compiler having to do the heavy lifting trying to put together the ideal instruction stream. It is actually a lot worse than it seems when I compare it with the original pentium, with its shallow pipeline and the relativly speaking lower memory latency of those days you could get away with a lot more without trashing performance.
Even if Apple through some magic manages to generate decent code for the in-order primary core (and it is not unlikely that they'd have to dump GCC since lots of hard-to-merge work would have to be done, and then they would lose the advantage of having a freely redistributable compiler) they will still be stumped on the vector units. Sure some of the heavier apps manage to make good use of Altivec, but that is a lot easier than trying to keep 8-16 vector units filled at the same time. Basicly only scientific and various extremely expensive pro applications would ever manage to invest the effort needed to actually manage to tap much of the power of the vector units (part because vectorization is hard, but also importantly because there are so many units to fill).
This all adds up to the Cell (and IBM's new in-order cores without the vector units) being quite unsuitable for any market where the applications are not written very specifically targeting the chip. It works for consoles since development is hardware-specific there, but putting out a computer with the Cell and expecting it to work out on peoples desktops is not in any way a good idea.
In the same vein, if a climate change that would kill us is "natural" I really don't care for natural. Better learn and figure out how to get a more unnatural but more friendly result if we at all can.
Please don't spread more confusion about the word "theory". The "theory of evolution" really is a theory in the sense that it is a falsifiable conjecture based on a large body of empirical observations. "Number theory" is of course not, it is there just a word used to refer to an axiomatic system in mathematics, and is as such necessarily "true" (though it is in itself unconnected with any physical objects and incomplete).
I am sure you know this and intended the fomulation, but too many people seem to have a somewhat poor grasp of how empirical and formal sciences relate so I just want to clarify.
Good work on the math there. Not that your opinion is of any interest to anyone anywhere either. Why is it that people feel that saying "this is uninteresting" is interesting for anyone else?
They also suck since it is near-impossible to see which button has keyboard focus, instead of the regular dotted rectangle used in the rest of Windows they have a slight lighter tint when active. Real easy to tell. I end up having to switch focus a few times before pressing enter every time just to be sure that the button I want is the active one.
Correct except for the "Coming soon:".
To put it this way, changing int's would be troublesome, be a performance hit and not give any advantages (since anyone needing a 64 bit word knows where to look already). Changing the size of the regular long int would maybe be more sensible since it is a bit useless to have it be defined as the same size as int as it typically is today, but really, it is not useful in any way other than to make the type hierarchy slightly nicer, and that is hardly worth the trouble.
- The user experience is only so-so.
- The standards are so numerous that it is hard to even have a general idea where all fit into the big picture.
- Writing a reader for it is such a huge undertaking that not even the largest and most successful businesses manage to pull it off well then something has gone very wrong.
then something is wrong.
The WWW should have been able to stabilize at some level years ago, making it possible to actually make a browser with a reasonable amount of effort. The underlying problem is not that hard, it is just a continuos pie-in-the-sky standardization effort ripping everything invented at any point apart in the next revision since they have decided that there are some better way to do it.
People have at this point come to accept it as the way things should work (being worried when there is no new standard for a year or two), but this is really a hopeless situation. If we had actually reached any level of comprehensiveness as far as web-based applications were concerned it would be less to think about, but the web is still in a primitive state.
Consider this coders and software designers:
- Make a presentation format that separates content from layout.
- Allow textual information with embedded images and external plugins/objects.
- Include some basic scripting, some basic widgets (buttons, textfields, drop-down boxes).
- See to that it is decently easy to screen-scrape, use with screen-readers and is resolution independent (may be done by automatic switching of layouting information).
Does anyone really feel that this has to be so complex that one can't complete it in under 15 years and one can't make it simple enough to actually make it possible for a hobbyist to implement a reader for? Sure the W3C has standards for a lot more, but that is part of the problem, the core is too huge. If one had a simple core it would have been easy to throw in MathML later and get people to pick it up, but since it is hard to in any sense even finish the core who is going to have time to make MathML work?
Web standards need a big sanity check.
Since it is based on the whole-system simulator Simics -- Yes, it does assume that the app runs in isolation, since all external stuff is just simics simulations.
Don't start with "Intel dual core is just a hack" now, while it is true that AMD's approach is more cleanly executed it is far from obvious that it will yield any significant advantages over Intels.
The by now classic Slashdot statement "Intel has just put two P4's on one die with some wires in between" is quite silly, since that is what multicore is. AMD just happens to have more wires :)
IE is tied to the OS in the sense of the widget toolkit and the user experience. It is used in a variety of places to provide rich formatted content. It does not run in kernel-space and it is not required for the kernel to function. It is impossible to separate IE from windows since the widget is much too commonly used both by Microsoft and third party applications.
So lets do this again: The OS is not the kernel, the OS includes a huge amount of user-interacting code. This UI code makes use of IE in many ways. Removing IE would require tons of software being rewritten, not because it is directly a "core" feature of Windows, but rather because of proper software reuse going on in a lot of Windows software.
Must say that it is very nice to see Solaris up there in the top in the tests that it was featured in. Seems Sun was not joking around when they claimed that Solaris 10 would be greatly improved on x86. As is often said around here; More choice is good.
Worldforge has not been an argument for open-source game development since 1999. It is at this point rather a shining example of how dysfunctional the typical (large-scale) OSS game project is.
It has been well-documented and well-known for ages how to do PNG alpha channels in IE. The stereotypical slashdot whine is about it not being done automatically with just the standard tag (not a huge complaint for the ambitious, the extra piece of code needed to make IE work with it does not interfere with other browsers that worked already).
A kludge winning out in the end sure would be consistent with x86 history.