Stripping out the stuff that is not actually used for anything interesting now and getting a real good simple filesystem is exactly what the lkml has been going for, Hans Reiser refuses to make ReiserFS v4 fit in the VFS however. Basicly it comes down to how one sees the filesystem future, Reiser wants filesystems to expand to do a whole lot of new stuff whereas the lkml favours keeping the simple filesystem abstraction that is in place.
It is somewhat important to note that not only does Apple do well building carefully on a classic filesystem, but really, Microsoft has a very advanced system that still maintains the simple filesystem at the bottom. Merging ReiserFS v4 under the current VFS (which can of course be extended a bit here and there as needed) does seem to be the correct way to me as well.
Are you sure you understand what ReiserFS is suppose to do? What about WinFS? I don't think compairing WinFS to ReisierFS is quite like compairing Qt to Explorer. The functionality of WinFS is (as I understand things) a proper subset of the functionality of ReiserFS.
Sorry, but ReiserFS v4 is a tiny subset of WinFS. I would say that the grandparents analogy is apt.
To clarify: ReiserFS adopts database concepts in two ways. It uses a B-tree variation to allow efficient hierarchical storage layout and it uses it to allow single-process atomicity. That is all.
WinFS on the other hand is an actual factual relational database (actually parts of MS SQL-Server) built on top of NTFS; a NTFS file is a special datatype among many others. One can specify relations and constraints as one would in a relational database. It has full atomicity (ACID), whereas ReiserFS's atomicity just gives a rollback local to a process. That is, any read or write may be transactionally inconsistent if there is more than one process dealing with the data whereas in WinFS one gets full support for transactions.
In addition to the above WinFS of course provides the obvious big end-user features; Fast queries over all the data in a relational way, and triggers that allow actions performed when data is changed or queried (both of which OSX provides in a slightly more ad-hoc way on the side).
So where does ReiserFS fit in? Well, the complaint that Hans Reiser has against WinFS is that not everything is a file, rather files is a special case mapping down to NTFS streams. Small auxilliary data is handled by other data-types in an SQL-like manner in WinFS, which to me at least seems like a quite sane approach. ReiserFS instead just optimizes the heck out of small files, planning to just take the UNIX principle to the limit, everything is a file, even if you just want to store a small integer. This makes everything fit into the classic filesystem namespace in a good way, but it is really less structured than the WinFS approach. WinFS relates whereas ReiserFS just provides really fast unstructured primitives.
Overall I don't expect ReiserFS to be overly relevant to the OSS answer to WinFS, mostly because I don't really expect a OSS answer to WinFS on that level. While Microsofts approach is a great piece of engineering is is also a huge amount of work. More likely is that the Apple approach will continue to be the important one; Just add the stuff needed to get the actually important end-user features today, work on the low-level programmer features later.
On the other hand ReiserFS v4 really appears to be very very fast. No doubt great features can be built on top of it, but on the other hand the classic VFS abstraction is a good thing. Swapping filesystems without impacting the userland is a feature that is really useful, so it seems fairly likely that the simpler approaches like Beagle will get to add the basic end-user features instead of fattening up the file systems (I highly disagree with Reiser that it is on the actual FS-level things should happen in the future). People who need databases can, *gasp*, use a database instead.
In fact, I am suprised to not yet have seen systems like Gnome and KDE fire up a stripped down PostgreSQL process or something similar to provide applications with an excellent database for whatever their needs might be. For Microsoft doing a thing like that hurts the bottom line (they do charge a fair bit of money for SQL-Server after all), but there is no reason why an OSS platform should not utilize the best technology it has available at every turn.
Oh well, getting off track. Summary: ReiserFS v4 is a tiny subset of WinFS feature-wise, it just does it very very fast.
To some part I am a bit sad that you don't see the beauty as I do, I consider this type of implementation the truly ultimate in abstraction. The outwardly visible interface is completely decoupled from the internals, leaving the chip designer free to come up with any amazing technique they please. I am also prepared to agree that simpler processors would be a good thing, but I really don't think that register renaming is a thing to axe for the sake of simplicity.
Dynamo is great technology, that we will no doubt see more of (creeping in from the side of JIT compilers like the.NET and Java platforms probably since they have the market). I were however still talking about things like the EPIC and the Transmeta VLIW, both are orders of magnitude harder to do something good on than just retuning code for a nice OoO chip on the fly. I think we are talking about different ends of things here though since you appear to be in favor of simpler but still not very explicitly parallel chips.
This is important. More transistors means larger chips, lower yield, higher price, more power consumption, need for more cooling with associated noise, and more room for (hardware!) bugs to creep in. Literally every processor on the market takes far less energy per work unit than ix86. Don't you think there's a reason for that?
I have trouble agreeing with this, sure there is some overhead involved, and a bit lower yield and higher power consumption follows. The point is that it isn't very much. The die area used by control logic that could be thrown out by architectual changes is fairly small. Some rather innovative work in instruction set design would have to be done (seeing how high-performance RISC's like the POWER4 have also dropped to microoperations and register renaming) and some flexibility would no doubt also be lost.
Also the Netburst chips are inefficient when it comes to power, but the K8 and Pentium M are not that easy to beat in work/watt, don't attempt to compare to a low-power ARM, it is far from a linear scale. On the other hand there is barely any chips to compare to in that performance class that don't employ tricks similar to the ones used in the top x86 implementations.
I understand where you are coming from though. It is not like the x86 should be accepted and research be stopped. It is just that there is not really any implementation that can compete with a K8 today, and it is absolutely not simple to make it happen either. What is possible is that the ARM might climb upwards in the market, it is how the x86 got to where it is once.
This is my last reply to this thread. Time to move on, everyone else has:)
Oh, I *do* think, 8 registers are a problem. Consider a superscalar processor with just two execution units and a four cycle deep pipeline. This isn't far fetched: modern processors have _more_ execution units and their pipelines are even _deeper_ (14 clocks for the K7 or something?).
In the simple example, up to 8 instructions are "in flight". At this point the register file of the ix86 is already exhausted, the next instruction definitely depends on one of the incomplete instructions. So even these few short pipes don't get filled. You need more registers to actually express more independent instructions.
You miss the beauty of register renaming, it does not matter for the in-flight instructions how many registers there are. They have already been assigned registers from the actual internal register file, which is much larger. That is; When the instructions come in they all use a snall number of registers, the issue logic analyses which registers actually need to be the same (that is, where the program is operating on the same actual data) and assigns them to the same internal register, otherwise it picks different ones for all instances of each register. Now all the dependencies that came from register reuse are gone and the instructions can be issued freely.
Somehow this strikes me as far more elegant that millions of transistors patching up what was already obsolete in 1979.
This is not nearly as important as it is sometimes made to look. Sure complex logic uses a lot of transistors, but the transistor budgets in most markets are mind-numbingly huge. Even if one has a very complex chip most of the budget ends up being spent on cache anyway. Have a look at the Prescott, the register renaming unit takes up a puny amount of die-space. Getting rid of it would not be any interesting gain.
BTW, "code morphing" has been proved in practice. Dynamo is a CPU emulator (aka VM) that emulates a PowerPC on a PowerPC. Sounds stupid? Yeah, that's what I thought, too. But the virtual CPU runs faster than the real CPU. Sounds impossible? Yeah, it does. There seems to be an awful lot of slack in the compiled code. Blame it on C, blame it on the compilers, whatever. But Dynamo simply works.
Dynamo runs PA-RISC on PA-RISC actually (natural since it is a HP project). While it is a classic example it is not exactly proof of code morphing, doing runtime optimization on code written for the architecture is a lot more straightforward than trying to run one architecture on another, and try to deal with tons of the processor logic in software. Dynamo can just reorder some blocks, insert branch hints and preloads and get good performance, a far cry from the make-the-issue-logic-in-software idea.
Your post sounded as if register renaming was enough: my point was that 20% increase of performance from going from 8 to 16 registers is a lot considering that the surface of silicon used to contain the additional registers is ridiculously small.
No no, I were only after the ILP effects. It is better to have more registers for the sake of avoiding tons of spilling. I can't disagree that the x86 is suboptimal in various ways, but the reality is that by good implementation work it has been brought up to, and beyond, the performance of much better thought out architectures. The x86-64 patches things up to be even better.
In theory yes, but are you sure that x86 do it?
No, can't say I am (secretive bastards:). I am less worried about keeping track of memory adresses, a static comparison array against all the internal registers in the first MEM stage would not be a big thing to add (and since the CPU has a whole instruction slot to deal with the spills and loads there does not seem to be much trouble in keeping an address list up to date). There are however some very nasty issues with not telling the memory subsystem what is happening. As such it realistic implementations have to send the write down to memory (well, cache) where it can be dealt with correctly. This of course yields slightly worse performance since it will cause more cache-line evictions and use up a possibly too small number of cache accesses per cycle. In most practical situtions though it still means that the spills will be quick (dispatching the write costs nothing in itself) and that the unspills will be quick (rename register back).
I am of course speculating at this point, neither Intel nor AMD is very forthcoming about the microarchitectual details of their processors. The above approach seems very plausible to me however.
8 registers is a bit on the lean side of things yes, considering the amount of code that has to be generated to handle it. I were just stating that instruction dependencies are not introduced by reusing registers on modern processors.
To somewhat offtopic comment on the x86-64 register extension: It is still an obviously good idea. Spill code does not actually have to hit memory as long as there are rename registers left, but having to insert tons of spill code will still beef up the number of instructions that have to be chewed through. As such the x86-64 fixes things up nicely. In fact, 16 register might really by enough. Going to 32 registers might yeild diminishing returns, 16 will be able to hold most activly used variables and since the spill code is not that expensive to execute (without the memory access) it is mostly enough to keep the spills out of inner loops. Lucky for all of us that the x86-64 appears to be becoming an universally accepted extension to the x86 architecture.
Register renaming and microoperations being leveraged in modern RISC implementations (POWER4 and thus the PPC970) just shows the success of the approach, now even the ever so popular PowerPC instruction set is considered too complex and limited to be executed directly. This really shows how well implemented the x86 is these days, while it was driven by a greater need it still had (and still has) a lot of very good designs before the competition got there.
Just one small comment: "in pratice the loss is even greater as the new register are disadvantaged by having to use bigger instruction to use them" is a dubious argument since having more registers necessarily means that larger instructions have to be used. Considering the performance of a 16 GP register architecture if a register can be decided with 3 bits is a somewhat pointless exercise. The x86 has a very space-efficient instruction encoding no matter how one looks at it (incidently 'space-efficient' is probably the only nice thing one can possibly say about it:).
Well, _C_ compilers are bad. That's not a fault of the compilers, it's to blame on C. If only people would put some effort into modern languages and actually using them...
Yeah, this is to some extent true. OoO chips are a nice deal though since they of course also benefit from better compilers, even the complex predicting OoO chips hedge their bets and include a few SIMD units in the mix to be able to capitalize easily on explicit parallelity. But to be practical; Most languages in popular use today are not very easy to get to run well on an Itanium.
In the meantime the sensible thing to do is not throwing yet more silicon on OoO execution, but doing this in software _at_runtime_. That is, Transmeta's code morphing is right. HP's Dynamo is also the right thing.
There is no real reason to throw more silicon on complex logic. As I insinuated in my post the wall has pretty much been hit as far as ILP extraction goes. Software solutions are interesting, it is a bit steep to call them "the right thing" at this point since they haven't really proved themselves in practice. It seems likely that we will see a lot more work in that area however.
A sensible instruction set is also of benefit. On an ix86 with its measly 8 almost-general-purpose registers, a lot of instructions depend on each other. You get better results with more registers.
This is not really a big problem in practice with the heavy renaming going on in modern x86 implementations (the Northwood has 128 internal registers, the K8 has 96 I believe). As soon as an instruction is decoded all registers used in it are changed to ones from the much larger "actual" register file. Independent code reusing the same register will be correctly renamed to different internal registers and run in parallel. There is some level of overhead involved, but it is a very effective technique in practice.
Are there reasons other than poor support from Micorsoft for Itanics massive failure? Is it a poor arcitecture?
In the world of good compilers originally envisioned by HP/Intel: No.
In practice: Yes.
Why? Because compilers aren't nearly as good as HP/Intel hoped but state of the art Out-of-Order processors are great. There is only so much theorethically possible ILP to extract in regular code, and good OoO chips extract most of it in an automatic fashion from existing code. So the hardware guys did a better job here than the software guys, and the Itanium bet on software.
To clarify on OoO processors doing most of the possible work in extracting ILP: Even if the instruction window was increased to infinity (that is, all ILP is always found) it would still not yield dramatically much better performance (I have seen estimates of about 25% best-case). So even with a perfect compiler there is just not much to gain, and we do not have perfect compilers. This very high level of performance in extracting ILP is what is forcing the new shift to TLP with architectures like the Sun Niagara.
I don't think we should be pleased that the Itanium failed. As I have often discussed in the past I think Intel really deserves a lot of credit, they are the undisputed top dog in the market, and despite that they are also one of the companies that consistently attempt new different approaches in high-profile products. Neither the Itanium nor the Netburst (which really is interesting and innovative technology) worked out well, but it is trying things that makes technology move forward.
That's not to say that AMD is a bad company, they managed to make the best x86 implementation yet, which is great (though I still consider the K7 to have been the golden age since their pricing structure truly was incredible then).
I mean, why not support OpenDocument and sell office to work with it? Massachusetts seems to be searching a good document format, they don't seem to say clearly "we want openoffice", they could sell more office copies if they supported the Opendocument format
I don't think it is suprising at all. The so-called "OpenDocument" format is nothing other than the OpenOffice format (much more so than the other way around, the OpenOffice format was standardized rather than OpenOffice adopting a standard). Going out of their way supporting the attempts to make a competitors format into an industry standard is not really devious, it is the sane thing to do.
Sure things would be easier for the rest of us if Microsoft adopted OpenDocument, but it is neither suprising nor evil that they don't.
I think the point here is that just because someone writes something they call an open standard does not make it a standard that everyone should be compelled to follow.
I am having trouble phrasing this much clearer, but I am going to give it another shot:
The larger the difference between revisions the less chance a large software product has of ever making it to a later revision. If revisions change often and a lot that means that the industry will be filled with large software projects stranded on each possible revision. As a professional it then becomes hard to have a grasp of "Java" as it is actually used, since there are many very different revisions in active use all over the place.
Now Sun does this fairly well, 1.5 was a large change, but they don't seem to be going to do so again. Nor was any of the earlier versions that disruptive (1.2 was somewhat big, but mostly stuff like AWT/Swing, which was and is less important). Having some similarity makes it possible for the industry to move forward with revisions.
It is not a matter of just backwards compatibility, software is never "done" so it will have to be dragged along. Backwards compatibility makes it possible to stay on an older revision of Java, some coherency in the language updates is what makes it possible to move to newer ones (when a new module of side-project is made for instance, possibly refactoring some other part if time allows).
Consider the extreme, if Sun changed Java so much that almost no skills and code from the previous revision carries over to the new (in the coherent codebase sense, not the backwards compatibility sense). The industry using Java would immediately fragment, there would be pre-'version' Java and post-'version' largely forever, anyone working in the industry would have to know both very different languages. Now consider if Sun does that five times.
What I am going for here is that Sun is doing the right thing being a bit careful with updating Java. Backwards compatibility is the basics, have to have that. It is also important however that changes like 1.5, while very nice, don't happen too often. Industry workers will have to juggle the differences in their minds for the next decade or so, but thanks to the changes not being too fundamental most companies will move on to later revisions when given opportunity, and it is not that hard to remember two revisions. As long as Sun isn't run by people like "Billy Gates" above who feel that languages should be revised all the time to add the latest bells and whistles things will be fine as they are.
Seems it did not work to have a part answering this question ahead of time, so I will just quote myself:
Some people might now just say "so stick to one version of Java and let the rest of us have new features". The problem is that doing so will fragment the language badly. People will have to not just learn one revision, they will have to learn a new one for each job they do, and then typically juggle the differences in their minds. Making the actual situation much more complex than the language appears to be when only considering each revision by itself.
This is not so much about me as it is about the Java ecosystem, real work and all that. It is fine for hobbyist and quick hack languages to rev often and a lot, but to actually get a workable climate for big commercial systems there has to be some coherency.
Notice Python which is popular with hobbyist hackers and has a bit of success here and there in more "commercial" settings. The difference is that most big systems that involve Python in some way stick to Python 1.5.2, a classic baseline version. This works out decently for Python since it is not usually the main platform for any big system (more support scripting and such), but Java is meant to be (and is activly used) at the core of very big and important systems all over the industry.
I see no problems with the current situation. While no one but Sun has really dared touch the core language and bytecode there is a very lively OSS community surrounding Java. Considering that the language and bytecode are really a rather small part of the platform as a whole it is probably a good thing for the community that they are kept relativly fixed.
Personally I get a bit worried when people talk about "falling behind" for a language (or major library for that matter). Java gets updated, in major ways, every few years. Since the language is the very basis for applications it cannot however run around and change all the time, it is supposed to be the vehicle of delivery for applications. If the language is so completely wrong that is needs to be changed in a major way one might as well instead create a new lanaguage.
The basic thing here is that while end-user applications should evolve as much as possible lower-level libraries and languages can not. There are probably billions of lines of Java out there, there are tools that parse Java code, there are languages targetting the JVM, there are libraries in turn relying on Sun's libraries. Changing the playing rules (even without breaking backwards compatibility) would invalidate a lot of work down the line.
I for one rather hope that Sun does not plan to add as major changes in 1.6 as they did in 1.5. This is not a hunt for some glorified ultimate language, there is real work being done that should not be constantly disturbed.
Some people might now just say "so stick to one version of Java and let the rest of us have new features". The problem is that doing so will fragment the language badly. People will have to not just learn one revision, they will have to learn a new one for each job they do, and then typically juggle the differences in their minds. Making the actual situation much more complex than the language appears to be when only considering each revision by itself.
Now of course there is.NET, which is a fine platform as well. I don't see that much need to update Java any more in response to it however, 1.5 added the most important bits. Doing anything more major soon would just make the relationship between Java 1.4 and 1.6 meaningless, people could just as well switch to.NET as go to another completely different platform.
It is completely and in every way legal. The only real restriction that Sun has is that the implementation has to pass their certification to be able to use the Java logotype and be called "a certified Java implementation".
It is more than a bit expensive to pass the certification however so the open source projects will probably never do so (though some company might push through one specific version at some point). It is not really an all that important point however, the technology and specification is all legal to implement.
It is of course different for different people, but I simply cannot take the loading times of Ridge Racer (haven't tried Wipeout so I don't know how the loading is). It is a slight annoyance on consoles, but to me it is a fatal flaw in a handheld. The most important use I get out of a handheld is the oops-15-minutes-of-random-free-time-playing. As such I need the game to be quick to get going or I wont bother playing.
I hope that the later generation PSP games shape up on the technical side, but also in the style. Porting older console games over does not really yield what I am after in many cases, often they require a longer time playing each time you start to get entertaining.
It would be a shame if Nintendo's monopoly in handheld gaming survived, some good competition would be nice. But I really have to favor Nintendo this time around. The PSP is beautiful and powerful, but the DS is cheap, more scratch-resistant, more innovative and the game library looks better.
This is somewhat odd logic since Intel owns the 1-4 CPU server market, no one comes close to shipping the number of processors they do there. Unless Apple intended to start making (actual) supercomputers this seems to be a perfectly valid move to continue taking on the server market.
Mostly correct, except that 8 MBit/s is the limit for most Swedish households at this point (and 24 MBit/s is very commonly available at this point). There is an ongoing upgrade effort so it is all coming around.
The broadband availability in Sweden is not all that fantastic (the 8 MBit/s ADSL is most common), but the infrastructure is at this point great. 90% of the population are reached by the fiber backbones at this point, it is mostly the ISP that have not really gotten things rolled out beyond ADSL in non-urban areas. On the other hand lots of villages just set up a "company", rent backbone access and run ethernet between the houses. Thanks to good infrastructure this is in fact a very cheap approach if you get going.
Sun the only company behind Solaris? Sure there might not be a bunch of companies who are ready to throw lots of paid developers full-time on the OpenSolaris project, but it seems quite likely that a lot od oldtime Solaris system administrators could be very likely to send in a bug-fi for any sufficiently annoying problem they find at least.
So Sun might not get tons of free developers, but they are likely to get a lot more skilled "eyeballs" as it is often called around here. It is probably even more important that Sun can now give the customers the feeling that they are in control of the platform on a level that they are comfortable with, another big win.
Overall I doubt that Sun goes into this with the idea that they will get a ton of developers or anything like that, but there are other (many very often touted on Slashdot) advantages of open-source that they are pretty much guaranteed to get.
3) People who want a *nix solution and will pay for it/support.
4) People who need the 'technical excellence' or a special feature that can only be had in Sun's product(s) compared to 'vanilla' Linux?
I'll guess these two. Joining Red Hat and Novell fighting for market-share is not at all a bad idea, Sun has a few aces up its sleeve (being big, old and having a fairly good reputation makes making a dent quite possible). Sun really does have some real technical advantages also, not really running on the low-end x86 hardware (though Solaris 10 sure is no slouch there either) but rather by promising future safety by offering plentiful and very powerful migration paths within their own product lines.
Linux sure does not have anything to worry about as such, but this does seem to have worked out as a smart move for Sun. While Linux will no doubt stick around it seems quite possible that Sun with these moves might not be doomed to a narrow niche either. Seeing how this is really betting the company (really going for the x86 offerings and open-sourcing their chief technological asset) I am quite impressed by Sun.
At any rate it is nice to see some competition on Linux's terms, oldtimers fading away further and further into obscurity as AIX and HP-UX are doing is worse for the industry as a whole.
This might have been an interesting argument if it was disabled/removed from XP. Which it is not (checked two different machines and installations of XP SP2, the service is present and running on both). Microsoft released a patch for the problem targeting XP, 2000 and 2003 Server earlier this month.
So I maintain my position that Microsoft has handled security in an appropriate manner when it comes to this issue (and most issues as of late).
Oh, they clearly did not do it first. The security push was very late in fact. Just pointing out that for Windows 2000 it was not that strange that it did not ship with automatic updating (few systems at the time did). On the other hand Microsoft has made a huge effort to rectify the situation, so it mostly comes down to the system administrators being the ones to blame for this.
One thing that really should be pointed out again (it is around on the news also) is that this is an exploit for an already patched exploit. The exploit is in fact most likely constructed by disassembling the Microsoft patch to discover the flaw. I know that I am a bit of a Microsoft apologist on Slashdot, but that really is because the Microsoft bashing is often ill-founded.
In this case Microsoft have really done everything any vendor can ever do in this kind of situation. They got the patch out there before any exploits were made, they have a complete patch system to distribute it (bordering on obnoxious when it nags you to reboot after updates). No open-source software could have done better, and despite all this the infection is apparently rampant.
Now if only the patching system had been in place when Windows 2000 was first released (on the other hand, how many OS's had automatic patch checks in 1999?) things might have turned out better. Or if the userbase (at least on a bigtime news network that really should have a big staff of system administrators) would actually get the patch system, or at least the patches. But it is just not meant to be I guess.
That would be a piss poor comparison. Pentium M is not nearly as radical a departure from the Pentium III as K8 is from K7. The K8 jump from K7 is more akin to the Penium Pro jump from Pentium 1. Pentium M is a great design, but it is not that radical a departure from the P-III.
The Pentium M changed the pipeline (a lot), the bus, the cache system, the instruction decoding, added microop fusion, revamped a ton of internal logic for the power consumption control. The heritage is there, notably in it having the same execution units, but the redesign is huge.
Have a look at the K8 and K7 architectures, same deal there, same execution units remain, including the K7 pipeline split. The pipelines have been lengthened by two steps (going from 10 steps to 12 for integer and from 15 to 17 for floating point), a smaller change than featured in the Pentium M. Decoding is updated in the K8 as well (almost always is), and some instruction handling tweaks here and there. While it is a great design it is extremely clearly a descendant of the K7. There are big changes like the 64 bit'ness and the integrated memory controller, but other than that it is mostly a question of a lot of tune-ups and small redesigns on the successful K7 core.
Also I don't believe for a second that the P4 was half-hearted (what is it with the conspiracy theories around here), the Itanium was always meant to be a server chip to compete with the RISC's that were at the time dominating that market.
AMD won the 64 bit war in the sense that their instruction set approach ended up on top, on the other hand Intel easily ships far more 64 bit x86's than AMD at this point.
Also it should be noted that the Pentium M is like the P3 in much the same way the K8 is like the K7. It is a very redesigned and improved core, so the ancestry in itself is no sign of it being an old design. As such I am not that sure that the new core wont be a Pentium M derivative as well, possibly simply a take on the Israeli Penium M by on of the US design teams.
Otherwise I very much agree with you, the CPU projects at Intel are probably all x86 at this point, so we will probably just get to see Intel "get back on the track" after the somewhat failed experiment with the P4.
Unfortunately this misses the depth of the features in Office. The shared files also feature merging, conflict resolution and unified modification histories (together with a special mode to review the differences between revisions), and this is just things I remember off the top of my head in Office 97. Later versions apparently include things like fine-grained ACL's for parts of the documents and such also.
To some part it is easy to miss how deep Office features run, the typical free alternatives offer the 10% of functionality that is used 90% of the time, it is just that most real world use situations of Office (in a corporate environment) will use one single feature out of those 90% which they dont want to do without.
Overall it is not a coincidence or dumb luck that Microsoft Office is the success it is, there really are no alternative that actually manages to provide even a fraction of all the in-depth features. On the flip side KDE really is doing a lot of nice fundamental work which will allow a lot of useful functionality easily, and this really if more important than spending forever trying to get OpenOffice to feature-parity with Office (which I actually consider to be a nearly hopeless project that wont actually change anything even if it succeeds).
Slashdot Mirror
It is somewhat important to note that not only does Apple do well building carefully on a classic filesystem, but really, Microsoft has a very advanced system that still maintains the simple filesystem at the bottom. Merging ReiserFS v4 under the current VFS (which can of course be extended a bit here and there as needed) does seem to be the correct way to me as well.
Sorry, but ReiserFS v4 is a tiny subset of WinFS. I would say that the grandparents analogy is apt.
To clarify: ReiserFS adopts database concepts in two ways. It uses a B-tree variation to allow efficient hierarchical storage layout and it uses it to allow single-process atomicity. That is all.
WinFS on the other hand is an actual factual relational database (actually parts of MS SQL-Server) built on top of NTFS; a NTFS file is a special datatype among many others. One can specify relations and constraints as one would in a relational database. It has full atomicity (ACID), whereas ReiserFS's atomicity just gives a rollback local to a process. That is, any read or write may be transactionally inconsistent if there is more than one process dealing with the data whereas in WinFS one gets full support for transactions.
In addition to the above WinFS of course provides the obvious big end-user features; Fast queries over all the data in a relational way, and triggers that allow actions performed when data is changed or queried (both of which OSX provides in a slightly more ad-hoc way on the side).
So where does ReiserFS fit in? Well, the complaint that Hans Reiser has against WinFS is that not everything is a file, rather files is a special case mapping down to NTFS streams. Small auxilliary data is handled by other data-types in an SQL-like manner in WinFS, which to me at least seems like a quite sane approach. ReiserFS instead just optimizes the heck out of small files, planning to just take the UNIX principle to the limit, everything is a file, even if you just want to store a small integer. This makes everything fit into the classic filesystem namespace in a good way, but it is really less structured than the WinFS approach. WinFS relates whereas ReiserFS just provides really fast unstructured primitives.
Overall I don't expect ReiserFS to be overly relevant to the OSS answer to WinFS, mostly because I don't really expect a OSS answer to WinFS on that level. While Microsofts approach is a great piece of engineering is is also a huge amount of work. More likely is that the Apple approach will continue to be the important one; Just add the stuff needed to get the actually important end-user features today, work on the low-level programmer features later.
On the other hand ReiserFS v4 really appears to be very very fast. No doubt great features can be built on top of it, but on the other hand the classic VFS abstraction is a good thing. Swapping filesystems without impacting the userland is a feature that is really useful, so it seems fairly likely that the simpler approaches like Beagle will get to add the basic end-user features instead of fattening up the file systems (I highly disagree with Reiser that it is on the actual FS-level things should happen in the future). People who need databases can, *gasp*, use a database instead.
In fact, I am suprised to not yet have seen systems like Gnome and KDE fire up a stripped down PostgreSQL process or something similar to provide applications with an excellent database for whatever their needs might be. For Microsoft doing a thing like that hurts the bottom line (they do charge a fair bit of money for SQL-Server after all), but there is no reason why an OSS platform should not utilize the best technology it has available at every turn.
Oh well, getting off track. Summary: ReiserFS v4 is a tiny subset of WinFS feature-wise, it just does it very very fast.
Dynamo is great technology, that we will no doubt see more of (creeping in from the side of JIT compilers like the .NET and Java platforms probably since they have the market). I were however still talking about things like the EPIC and the Transmeta VLIW, both are orders of magnitude harder to do something good on than just retuning code for a nice OoO chip on the fly. I think we are talking about different ends of things here though since you appear to be in favor of simpler but still not very explicitly parallel chips.
This is important. More transistors means larger chips, lower yield, higher price, more power consumption, need for more cooling with associated noise, and more room for (hardware!) bugs to creep in. Literally every processor on the market takes far less energy per work unit than ix86. Don't you think there's a reason for that?
I have trouble agreeing with this, sure there is some overhead involved, and a bit lower yield and higher power consumption follows. The point is that it isn't very much. The die area used by control logic that could be thrown out by architectual changes is fairly small. Some rather innovative work in instruction set design would have to be done (seeing how high-performance RISC's like the POWER4 have also dropped to microoperations and register renaming) and some flexibility would no doubt also be lost.
Also the Netburst chips are inefficient when it comes to power, but the K8 and Pentium M are not that easy to beat in work/watt, don't attempt to compare to a low-power ARM, it is far from a linear scale. On the other hand there is barely any chips to compare to in that performance class that don't employ tricks similar to the ones used in the top x86 implementations.
I understand where you are coming from though. It is not like the x86 should be accepted and research be stopped. It is just that there is not really any implementation that can compete with a K8 today, and it is absolutely not simple to make it happen either. What is possible is that the ARM might climb upwards in the market, it is how the x86 got to where it is once.
This is my last reply to this thread. Time to move on, everyone else has :)
In the simple example, up to 8 instructions are "in flight". At this point the register file of the ix86 is already exhausted, the next instruction definitely depends on one of the incomplete instructions. So even these few short pipes don't get filled. You need more registers to actually express more independent instructions.
You miss the beauty of register renaming, it does not matter for the in-flight instructions how many registers there are. They have already been assigned registers from the actual internal register file, which is much larger. That is; When the instructions come in they all use a snall number of registers, the issue logic analyses which registers actually need to be the same (that is, where the program is operating on the same actual data) and assigns them to the same internal register, otherwise it picks different ones for all instances of each register. Now all the dependencies that came from register reuse are gone and the instructions can be issued freely.
Somehow this strikes me as far more elegant that millions of transistors patching up what was already obsolete in 1979.
This is not nearly as important as it is sometimes made to look. Sure complex logic uses a lot of transistors, but the transistor budgets in most markets are mind-numbingly huge. Even if one has a very complex chip most of the budget ends up being spent on cache anyway. Have a look at the Prescott, the register renaming unit takes up a puny amount of die-space. Getting rid of it would not be any interesting gain.
BTW, "code morphing" has been proved in practice. Dynamo is a CPU emulator (aka VM) that emulates a PowerPC on a PowerPC. Sounds stupid? Yeah, that's what I thought, too. But the virtual CPU runs faster than the real CPU. Sounds impossible? Yeah, it does. There seems to be an awful lot of slack in the compiled code. Blame it on C, blame it on the compilers, whatever. But Dynamo simply works.
Dynamo runs PA-RISC on PA-RISC actually (natural since it is a HP project). While it is a classic example it is not exactly proof of code morphing, doing runtime optimization on code written for the architecture is a lot more straightforward than trying to run one architecture on another, and try to deal with tons of the processor logic in software. Dynamo can just reorder some blocks, insert branch hints and preloads and get good performance, a far cry from the make-the-issue-logic-in-software idea.
No no, I were only after the ILP effects. It is better to have more registers for the sake of avoiding tons of spilling. I can't disagree that the x86 is suboptimal in various ways, but the reality is that by good implementation work it has been brought up to, and beyond, the performance of much better thought out architectures. The x86-64 patches things up to be even better.
In theory yes, but are you sure that x86 do it?
No, can't say I am (secretive bastards :). I am less worried about keeping track of memory adresses, a static comparison array against all the internal registers in the first MEM stage would not be a big thing to add (and since the CPU has a whole instruction slot to deal with the spills and loads there does not seem to be much trouble in keeping an address list up to date). There are however some very nasty issues with not telling the memory subsystem what is happening. As such it realistic implementations have to send the write down to memory (well, cache) where it can be dealt with correctly. This of course yields slightly worse performance since it will cause more cache-line evictions and use up a possibly too small number of cache accesses per cycle. In most practical situtions though it still means that the spills will be quick (dispatching the write costs nothing in itself) and that the unspills will be quick (rename register back).
I am of course speculating at this point, neither Intel nor AMD is very forthcoming about the microarchitectual details of their processors. The above approach seems very plausible to me however.
To somewhat offtopic comment on the x86-64 register extension: It is still an obviously good idea. Spill code does not actually have to hit memory as long as there are rename registers left, but having to insert tons of spill code will still beef up the number of instructions that have to be chewed through. As such the x86-64 fixes things up nicely. In fact, 16 register might really by enough. Going to 32 registers might yeild diminishing returns, 16 will be able to hold most activly used variables and since the spill code is not that expensive to execute (without the memory access) it is mostly enough to keep the spills out of inner loops. Lucky for all of us that the x86-64 appears to be becoming an universally accepted extension to the x86 architecture.
Register renaming and microoperations being leveraged in modern RISC implementations (POWER4 and thus the PPC970) just shows the success of the approach, now even the ever so popular PowerPC instruction set is considered too complex and limited to be executed directly. This really shows how well implemented the x86 is these days, while it was driven by a greater need it still had (and still has) a lot of very good designs before the competition got there.
Just one small comment: "in pratice the loss is even greater as the new register are disadvantaged by having to use bigger instruction to use them" is a dubious argument since having more registers necessarily means that larger instructions have to be used. Considering the performance of a 16 GP register architecture if a register can be decided with 3 bits is a somewhat pointless exercise. The x86 has a very space-efficient instruction encoding no matter how one looks at it (incidently 'space-efficient' is probably the only nice thing one can possibly say about it :).
Yeah, this is to some extent true. OoO chips are a nice deal though since they of course also benefit from better compilers, even the complex predicting OoO chips hedge their bets and include a few SIMD units in the mix to be able to capitalize easily on explicit parallelity. But to be practical; Most languages in popular use today are not very easy to get to run well on an Itanium.
In the meantime the sensible thing to do is not throwing yet more silicon on OoO execution, but doing this in software _at_runtime_. That is, Transmeta's code morphing is right. HP's Dynamo is also the right thing.
There is no real reason to throw more silicon on complex logic. As I insinuated in my post the wall has pretty much been hit as far as ILP extraction goes. Software solutions are interesting, it is a bit steep to call them "the right thing" at this point since they haven't really proved themselves in practice. It seems likely that we will see a lot more work in that area however.
A sensible instruction set is also of benefit. On an ix86 with its measly 8 almost-general-purpose registers, a lot of instructions depend on each other. You get better results with more registers.
This is not really a big problem in practice with the heavy renaming going on in modern x86 implementations (the Northwood has 128 internal registers, the K8 has 96 I believe). As soon as an instruction is decoded all registers used in it are changed to ones from the much larger "actual" register file. Independent code reusing the same register will be correctly renamed to different internal registers and run in parallel. There is some level of overhead involved, but it is a very effective technique in practice.
In the world of good compilers originally envisioned by HP/Intel: No.
In practice: Yes.
Why? Because compilers aren't nearly as good as HP/Intel hoped but state of the art Out-of-Order processors are great. There is only so much theorethically possible ILP to extract in regular code, and good OoO chips extract most of it in an automatic fashion from existing code. So the hardware guys did a better job here than the software guys, and the Itanium bet on software.
To clarify on OoO processors doing most of the possible work in extracting ILP: Even if the instruction window was increased to infinity (that is, all ILP is always found) it would still not yield dramatically much better performance (I have seen estimates of about 25% best-case). So even with a perfect compiler there is just not much to gain, and we do not have perfect compilers. This very high level of performance in extracting ILP is what is forcing the new shift to TLP with architectures like the Sun Niagara.
I don't think we should be pleased that the Itanium failed. As I have often discussed in the past I think Intel really deserves a lot of credit, they are the undisputed top dog in the market, and despite that they are also one of the companies that consistently attempt new different approaches in high-profile products. Neither the Itanium nor the Netburst (which really is interesting and innovative technology) worked out well, but it is trying things that makes technology move forward.
That's not to say that AMD is a bad company, they managed to make the best x86 implementation yet, which is great (though I still consider the K7 to have been the golden age since their pricing structure truly was incredible then).
I don't think it is suprising at all. The so-called "OpenDocument" format is nothing other than the OpenOffice format (much more so than the other way around, the OpenOffice format was standardized rather than OpenOffice adopting a standard). Going out of their way supporting the attempts to make a competitors format into an industry standard is not really devious, it is the sane thing to do.
Sure things would be easier for the rest of us if Microsoft adopted OpenDocument, but it is neither suprising nor evil that they don't.
I think the point here is that just because someone writes something they call an open standard does not make it a standard that everyone should be compelled to follow.
The larger the difference between revisions the less chance a large software product has of ever making it to a later revision. If revisions change often and a lot that means that the industry will be filled with large software projects stranded on each possible revision. As a professional it then becomes hard to have a grasp of "Java" as it is actually used, since there are many very different revisions in active use all over the place.
Now Sun does this fairly well, 1.5 was a large change, but they don't seem to be going to do so again. Nor was any of the earlier versions that disruptive (1.2 was somewhat big, but mostly stuff like AWT/Swing, which was and is less important). Having some similarity makes it possible for the industry to move forward with revisions.
It is not a matter of just backwards compatibility, software is never "done" so it will have to be dragged along. Backwards compatibility makes it possible to stay on an older revision of Java, some coherency in the language updates is what makes it possible to move to newer ones (when a new module of side-project is made for instance, possibly refactoring some other part if time allows).
Consider the extreme, if Sun changed Java so much that almost no skills and code from the previous revision carries over to the new (in the coherent codebase sense, not the backwards compatibility sense). The industry using Java would immediately fragment, there would be pre-'version' Java and post-'version' largely forever, anyone working in the industry would have to know both very different languages. Now consider if Sun does that five times.
What I am going for here is that Sun is doing the right thing being a bit careful with updating Java. Backwards compatibility is the basics, have to have that. It is also important however that changes like 1.5, while very nice, don't happen too often. Industry workers will have to juggle the differences in their minds for the next decade or so, but thanks to the changes not being too fundamental most companies will move on to later revisions when given opportunity, and it is not that hard to remember two revisions. As long as Sun isn't run by people like "Billy Gates" above who feel that languages should be revised all the time to add the latest bells and whistles things will be fine as they are.
Some people might now just say "so stick to one version of Java and let the rest of us have new features". The problem is that doing so will fragment the language badly. People will have to not just learn one revision, they will have to learn a new one for each job they do, and then typically juggle the differences in their minds. Making the actual situation much more complex than the language appears to be when only considering each revision by itself.
This is not so much about me as it is about the Java ecosystem, real work and all that. It is fine for hobbyist and quick hack languages to rev often and a lot, but to actually get a workable climate for big commercial systems there has to be some coherency.
Notice Python which is popular with hobbyist hackers and has a bit of success here and there in more "commercial" settings. The difference is that most big systems that involve Python in some way stick to Python 1.5.2, a classic baseline version. This works out decently for Python since it is not usually the main platform for any big system (more support scripting and such), but Java is meant to be (and is activly used) at the core of very big and important systems all over the industry.
Personally I get a bit worried when people talk about "falling behind" for a language (or major library for that matter). Java gets updated, in major ways, every few years. Since the language is the very basis for applications it cannot however run around and change all the time, it is supposed to be the vehicle of delivery for applications. If the language is so completely wrong that is needs to be changed in a major way one might as well instead create a new lanaguage.
The basic thing here is that while end-user applications should evolve as much as possible lower-level libraries and languages can not. There are probably billions of lines of Java out there, there are tools that parse Java code, there are languages targetting the JVM, there are libraries in turn relying on Sun's libraries. Changing the playing rules (even without breaking backwards compatibility) would invalidate a lot of work down the line.
I for one rather hope that Sun does not plan to add as major changes in 1.6 as they did in 1.5. This is not a hunt for some glorified ultimate language, there is real work being done that should not be constantly disturbed.
Some people might now just say "so stick to one version of Java and let the rest of us have new features". The problem is that doing so will fragment the language badly. People will have to not just learn one revision, they will have to learn a new one for each job they do, and then typically juggle the differences in their minds. Making the actual situation much more complex than the language appears to be when only considering each revision by itself.
Now of course there is .NET, which is a fine platform as well. I don't see that much need to update Java any more in response to it however, 1.5 added the most important bits. Doing anything more major soon would just make the relationship between Java 1.4 and 1.6 meaningless, people could just as well switch to .NET as go to another completely different platform.
It is more than a bit expensive to pass the certification however so the open source projects will probably never do so (though some company might push through one specific version at some point). It is not really an all that important point however, the technology and specification is all legal to implement.
I hope that the later generation PSP games shape up on the technical side, but also in the style. Porting older console games over does not really yield what I am after in many cases, often they require a longer time playing each time you start to get entertaining.
It would be a shame if Nintendo's monopoly in handheld gaming survived, some good competition would be nice. But I really have to favor Nintendo this time around. The PSP is beautiful and powerful, but the DS is cheap, more scratch-resistant, more innovative and the game library looks better.
This is somewhat odd logic since Intel owns the 1-4 CPU server market, no one comes close to shipping the number of processors they do there. Unless Apple intended to start making (actual) supercomputers this seems to be a perfectly valid move to continue taking on the server market.
Damn chinese plotting against us, we need to spend more money on the NSA to keep us safe.
The broadband availability in Sweden is not all that fantastic (the 8 MBit/s ADSL is most common), but the infrastructure is at this point great. 90% of the population are reached by the fiber backbones at this point, it is mostly the ISP that have not really gotten things rolled out beyond ADSL in non-urban areas. On the other hand lots of villages just set up a "company", rent backbone access and run ethernet between the houses. Thanks to good infrastructure this is in fact a very cheap approach if you get going.
So Sun might not get tons of free developers, but they are likely to get a lot more skilled "eyeballs" as it is often called around here. It is probably even more important that Sun can now give the customers the feeling that they are in control of the platform on a level that they are comfortable with, another big win.
Overall I doubt that Sun goes into this with the idea that they will get a ton of developers or anything like that, but there are other (many very often touted on Slashdot) advantages of open-source that they are pretty much guaranteed to get.
4) People who need the 'technical excellence' or a special feature that can only be had in Sun's product(s) compared to 'vanilla' Linux?
I'll guess these two. Joining Red Hat and Novell fighting for market-share is not at all a bad idea, Sun has a few aces up its sleeve (being big, old and having a fairly good reputation makes making a dent quite possible). Sun really does have some real technical advantages also, not really running on the low-end x86 hardware (though Solaris 10 sure is no slouch there either) but rather by promising future safety by offering plentiful and very powerful migration paths within their own product lines.
Linux sure does not have anything to worry about as such, but this does seem to have worked out as a smart move for Sun. While Linux will no doubt stick around it seems quite possible that Sun with these moves might not be doomed to a narrow niche either. Seeing how this is really betting the company (really going for the x86 offerings and open-sourcing their chief technological asset) I am quite impressed by Sun.
At any rate it is nice to see some competition on Linux's terms, oldtimers fading away further and further into obscurity as AIX and HP-UX are doing is worse for the industry as a whole.
So I maintain my position that Microsoft has handled security in an appropriate manner when it comes to this issue (and most issues as of late).
Oh, they clearly did not do it first. The security push was very late in fact. Just pointing out that for Windows 2000 it was not that strange that it did not ship with automatic updating (few systems at the time did). On the other hand Microsoft has made a huge effort to rectify the situation, so it mostly comes down to the system administrators being the ones to blame for this.
In this case Microsoft have really done everything any vendor can ever do in this kind of situation. They got the patch out there before any exploits were made, they have a complete patch system to distribute it (bordering on obnoxious when it nags you to reboot after updates). No open-source software could have done better, and despite all this the infection is apparently rampant.
Now if only the patching system had been in place when Windows 2000 was first released (on the other hand, how many OS's had automatic patch checks in 1999?) things might have turned out better. Or if the userbase (at least on a bigtime news network that really should have a big staff of system administrators) would actually get the patch system, or at least the patches. But it is just not meant to be I guess.
The Pentium M changed the pipeline (a lot), the bus, the cache system, the instruction decoding, added microop fusion, revamped a ton of internal logic for the power consumption control. The heritage is there, notably in it having the same execution units, but the redesign is huge.
Have a look at the K8 and K7 architectures, same deal there, same execution units remain, including the K7 pipeline split. The pipelines have been lengthened by two steps (going from 10 steps to 12 for integer and from 15 to 17 for floating point), a smaller change than featured in the Pentium M. Decoding is updated in the K8 as well (almost always is), and some instruction handling tweaks here and there. While it is a great design it is extremely clearly a descendant of the K7. There are big changes like the 64 bit'ness and the integrated memory controller, but other than that it is mostly a question of a lot of tune-ups and small redesigns on the successful K7 core.
Also I don't believe for a second that the P4 was half-hearted (what is it with the conspiracy theories around here), the Itanium was always meant to be a server chip to compete with the RISC's that were at the time dominating that market.
Also it should be noted that the Pentium M is like the P3 in much the same way the K8 is like the K7. It is a very redesigned and improved core, so the ancestry in itself is no sign of it being an old design. As such I am not that sure that the new core wont be a Pentium M derivative as well, possibly simply a take on the Israeli Penium M by on of the US design teams.
Otherwise I very much agree with you, the CPU projects at Intel are probably all x86 at this point, so we will probably just get to see Intel "get back on the track" after the somewhat failed experiment with the P4.
To some part it is easy to miss how deep Office features run, the typical free alternatives offer the 10% of functionality that is used 90% of the time, it is just that most real world use situations of Office (in a corporate environment) will use one single feature out of those 90% which they dont want to do without.
Overall it is not a coincidence or dumb luck that Microsoft Office is the success it is, there really are no alternative that actually manages to provide even a fraction of all the in-depth features. On the flip side KDE really is doing a lot of nice fundamental work which will allow a lot of useful functionality easily, and this really if more important than spending forever trying to get OpenOffice to feature-parity with Office (which I actually consider to be a nearly hopeless project that wont actually change anything even if it succeeds).