I don't see this as long lived
on
Ageia PhysX Tested
·
· Score: 5, Interesting
I really don't see a custom "Physics Processor" being a long-lived add-on for the PC platform. It's essentially just another floating point SIMD processor with specialized drivers for game engine physics. With multicore+hyperthreaded CPUs coming out very soon, the physics engines can be offloaded to extra processing units in your system rather than having to fork out money for a card that can only be used for a special purpose.
In addition, there's already a hideously powerful SIMD engine in most gaming systems loosely called "the video card". With the advent of DirectX 10 hardware which lets the card GPU write it's intermediate calculations back to main memory rather than forcing it all out to the frame buffer, a whole bunch of physics processing can suddenly be done through the GPU.
Lastly, the API to talk to these cards is single-vendor and proprietary. That's never been a long term solution for longevity (unless you're Microsoft), so it won't really take off until DirectX 11 or later integrates a DirectPhysics layer to allow multiple hardware vendors to compete without game devs having to write radically different code.
So, between multicore/hyperthreaded CPUs and DirectX10 or better GPUs with a proprietary API to the card... cute hardware but not a long term solution.
I guess if you're counting ocean waves you could call it realtime.
Realtime has absolutely nothing to do with the relative speed of the OS or GUI. What it means is that the OS can *guarantee* a response to an input within a defined period of time. While that time is typically very short, you could still technically be realtime if you could demonstrate guaranteed response within 24 hours (though you wouldn't be particularly useful).
Again, technically that's "hard" realtime. "Soft" realtime system are just pretenders that can't really guarantee anything and just look kinda like a preemptive OS with priority levels and the like.
Linux is not a realtime system (without very specific extensions anyway). You don't really want a general purpose OS as "realtime" anyway - it just doesn't help things at all and tends to complicate the processing model.
CE 5.0 (and probably 6.0) are not hard realtime systems. Even at the OEM level (where you can actually write real ISRs) there's no guaranteed response time, just a bunch of realtime looking stuff. At the Application Developer, or even Device Driver level (ISTs, not ISRs) you are so far from realtime it really doesn't make much sense to talk about it in those terms.
If you read between the lines on this report from Microsoft you can glean most of what I've said.
Count yourself lucky that you didn't have the misfortune to have to deal with buggy video drivers then.
Buggy video drivers would take down NT 3.51 just as fast as NT 4.0. If you'd read my post, you'd notice that the video driver crashing in user mode in 3.51 would bring down csrss.exe which resulted in the machine blue screening anyway.
I dealt with plenty of buggy video drivers in 3.51 and 4.0 and the end result was the same in either case - a blue screen.
Now, you are absolutely correct that a command prompt would have been better than a blue screen, but that's not the way it worked in 3.51 so you can't make a case that moving the GUI to the kernel reduced stability because in either case a bug led to a blue screen.
Never said it (they) did. Actually if you look at your direct quote from my post, I used the term "paradigm".
Granted, but reading it literally certainly implies that NT/XP sat over Windows/DOS. Now that you've expanded on what you meant, I definitely agree that the paradigm was lifted straight from Windows/DOS (or probably more strictly OS/2 1.x, then morphed to Win3.x).
In an interesting followup, I don't think moving the GDI into the kernel was that big of a deal. Most operating systems have done this to some extent and it really didn't affect the stability of NT at all. I read big articles at the time on how terrible it was that the GUI crashing would crash the OS, but guess what - grab your NT 3.51 installation and terminate csrss.exe and see what happens. Blue screen. (This still happens on Vista btw). THAT is bad design, for sure.
Again, interestingly enough, the new GUI drivers are going back the other way with the majority of the driver code being pulled back out to user mode and a small amount being left in the kernel as a conduit to the hardware. A whole bunch of other drivers are now user mode apps (mostly USB and Audio drivers). Interesting the way the wheel spins.
And, I absolutely agree that Windows doesn't stand up to the big commercial Unixes (or non-Unixes for that matter) in terms of stability and reliability. Getting better, but not there.
Look at Unix/Unix like OSes. A port to the next generation or a different incarnation is often a recompile and nothing else. Why? Because there is a stable API! Nobody uses platform specific stuff, unless there is no choice.
Are you for real?
This is true of user level applications, but certainly not for system level ones. The stuff in Unix is hideously incompatible across incarnations - try parsing/proc on something other than Linux and I'll guarantee that things will fail badly (as one example). Try recompiling a Linux x86 driver on NetBSD/PPC and I seriously doubt you'll experience much joy.
RSA writes driver level code (to keep their proprietary algorithms sekrut) and hooks it to the Windows GUI logon process - that's something that changes between desktop managers on Unix, let alone versions or even incarnations! There may be pseudo-stable APIs there but there's an awful lot of redundancy and it's not exactly a clean landscape (xdm, kdm, gdm, whateverdm etc.)
Now, I'm not remotely suggesting Windows is any better than Unix in this regard, but the only thing it really does have going for it is there's a lot fewer "versions" out there. Like Unix, the core APIs are very stable. It's the fringe and special purpose stuff you have to worry about.
Note also that the same thing happens to Unix from time to time: shadow passwords broke a bunch of stuff, MD5 hashes broke more stuff, pam broke a whole different set of stuff, etc.
crippled layering of a multi-user paradigm on top of what started out as a single user design (NT/XP over Windows/DOS)
Oh, please! Learn your OS history. NT/XP never sat on top of DOS, Win3.x or Win9x. The original NT design was actually supposed to support multiuser UI sessions out of the box (hence the entire UI being designed around a client/server RPC model) but it didn't end up that way for any number of performance and time-to-market constraints.
The Vista design could best be described as a multiuser kernel that got hacked up to service a single user GUI that looked a lot like the existing single user product that was on the market, which was then moved into the kernel to improve performance, which then got a multiuser terminal layer hacked over the top (using the multiuser not-GUI-part-of-the-kernel that was already there), which then got morphed into "Fast User Switching".
The multiuser UI in Windows XP/Vista is most definitely a hack, but it's got nothing to do with Win3.x or DOS.
As for the original context - (yawn). OS upgrades change APIs. MS has been working on security so their security APIs are going to change. If you tie yourself to MS, then you get to do some work to use their new APIs. Nothing to see here - move along.
Agreed, but when compared to other games (like Everquest) which has the outdoors broken up significantly more granularly then you see where the scalability is hampered.
You're thinking about it the wrong way. It's OO in the sense of stdin and stdout, which are object streams and not character streams.
For example, "dir" returns a stream of objects which are of type "File". If you pipe that output into another command then it has the full file information available to it from the object stream, so can act on the file contents, file name, file type, file dates etc if it chooses. Another command "list-users" may output a stream of user objects. Something else may output a stream of some other type of object. etc.
From there, and some "glue" type commands which allow object transformation, property selection and taking of subsets of objects you can build up a fairly powerful command line that looks like a unix shell but is kinda different too when you think of all the metadata going between the commands.
Naturally, as every.NET object has a ToString() method, if the final output actually ends up on the console then ToString() is called and you get a result.
Kinda cool. Not sure if it will be more or less useful than the unix model though.
One of the interesting decisions Blizzard made in developing WoW was to do away with the concept of "zoning", which is prevalent in a lot of other MMOGs. This implicitly limited their scalability as games with "zones" typically split the zones over separate physical machines to balance the load to a manageable level. It also allows a degree of network scalability as you can route different zones along different network paths.
In making the entire world effectively zoneless, Blizzard made their scalability a lot more difficult as you no longer have the "neat" option of just tossing a few more machines into the rack, giving them their own dedicated bandwidth and migrating zones from overloaded boxes onto the new ones.
Also, I have to say that catering for the million or so US players (forget how their demographics break down) should have given them a heads up on the need for a whole slew of heavy duty data centers. Like it or not, that's the price you have to pay for a wildly successful game.
Drivers aren't signed until they are tested and certified by Microsoft, right?
No, this isn't the case. You can sign drivers yourself if you have a code signing cert from Verisign and have registered with MS to get a cert signed by them. The manditory signing is only on x64 versions too.
This means "beta" drivers will be signed by their developers and runnable on Vista. The net effect of the code signing is it just raises the bar a little on who can write drivers for the system, and potentially causes headaches for open source drivers like ext2 and winpcap (which is where I see the main problem).
Pentium based machines are also vulnerable to a denial of service attack from a hacker with physical access to the machine and in the possession of a large axe. Should the attacker be wielding a pair of axes (one in each hand) then the attack would constitute a distributed denial of service.
Whoa. Whoever tried to sell Exchange into that installation needs to be shot. Like Notes, it's not designed to be an ISP email system. People need to get off the IMAPd vs Exchange kick and realize that they are very different products. No ISP should *ever* look at Exchange for their customers.
In terms of Exchange vs Notes, I just can't get past the past 5 years of absolute misery and horror that Notes has inflicted on me to even fight against Microsoft on this one. IBM needs to just dump Notes and come up with something that can truly compete for user mindshare.
Microsoft's methods to going into the AS400 market is simple - take what they have and put more and more stuff onto it. Sharepoint, Exchange and SQL Server are doing fairly well so you can expect MS to be leveraging those products to give away just a couple more things until you suddenly find you don't need your AS/400s any more. IBM doesn't help its own cause much there either by shipping full J2EE environments on Windows and AS/400s.
I have no doubts that Notes servers are easier to maintain than Exchange servers btw. I'm just continually in awe at the stupidity of the Notes client interface. If they could get that looking and running as smoothly as Outlook does (yeah, I know, viruses etc.) then I'd be arguing the Notes thing all over the place, but it just hasn't happened and it's really hurting Notes badly.
I agree 100%. IE has ActiveX. Mozilla has plugins. Both are extensibility interfaces that are essential for web browsing. Properly implemented and secured they are a great asset for the end user. Improperly implemented they just become a security or usability nightmare.
I'm not convinced either browser does it well yet but Firefox does seem better than IE.
Sorry, I have to admit I missed that little word uper bound. In fact it is not nice of you to make a conversation over 3 posts and finally hit me with that into my face.
It's not nice of me to make you miss a word I clearly posted and used? You need to wear more tinfoil on your head so my mind control rays affect you less.
A very simple situation where the C model fails is: compile a program to Pentium code and let it run on a Pentium 4.
Yes - and that is the case that most Java nuts use to "prove" Java is faster than C. However, it's not the case I was arguing. My point is that if you know your target platform then C will be faster or at least as fast as Java because you can compile it to that specific platform.
In the absolute worst case, the argument falls back to the fact the entire JVM is written in C, so I can happily make the argument that C is provably as fast as Java in every situation simply because Java is really executing C code anyway. Yes - it's cheating but it just shows the futility of the Java argument.
C/C++ optimization is not "cool" in the academic community but it's very much alive and still very much an area that companies spend billions of dollars on. A CPU lives and dies by the efficiency of its C compiler. The same cannot be said for JVMs.
You can express every problem in C that you can express in Java. Excluding C libraries is just stupidity, unless you want to exclude java.lang, java.util and all the other stuff from Java as well, which makes the entire language useless.
So, no. Unless you change the bounds of the argument, fully optimized C will always present the upper bound of performance for fully optimized Java when you know the target platform. To suggest anything else is simple ignorance of how computers work.
Just posting in support of the parent. As bad as Microsoft is, I'd happily use Outlook/Exchange over Lotus Notes any day of the week. In fact, I'd rather just go without email altogether than use Lotus Notes. It's seriously the worst end-user email product I've ever had the misfortune to have forced onto my desktop.
Not guilty. However, you seem guilty of Java bigotry and failure to read and understand research papers.
You do realize that array bounds checking is eliminated by modern VM's?
Of course, and I've read the paper you linked. Thanks for telling me stuff I know and even recognized in my previous posts by saying that Java has an upper bound at C's optimized performance. *If* the runtime checks can be removed then Java array access is as fast as C. If they can't then Java is slower.
The Java version of Quake performs faster than the C version
The C version was compiled for a 386. Recompile it and optimize it and you'll get a hell of a lot more performance than the original. Do you really think that game developers are all idiots for using C/C++ for their game engines instead of Java? Here's a big smack with the cluestick for you - they use C/C++ because it offers better performance when optimized. When I see a game released under Java then I might give you some credibility but until then you're just another tired old bigot comparing a modern JIT with a C program compiled for a 10 year old processor.
Your other benchmarks are just as telling - they compare Java code with unoptimized C code using the worst possible compiler for performance (gcc). You do realize modern C optimization allows the developer to specify pointer aliasing, efficiently use registers and processor features through intrinsics and other optimizations that the JIT uses in the cases that you demonstrate performance advantages over C/C++ code.
Simply put, the only cases where you demonstrate Java advantages are in comparisons to unoptimized C. If all you have is comparisons using C as a baseline rather than comparisons with optimized C then you're deluding yourself and pitching out the lie that Java *is* as fast as C rather than the truth that Java has an upper bound at optimized C's performance.
Java and Hotspots optimize on the fly. C coders optimize better through runtime analysis and knowing meta-information about the code that a compiler can never hope to know.
I'm not narrow minded, I'm just not a Java bigot like you. The simple fact is you can optimze C code more than you can optimze Java code. All the studies (which I have looked at extensively) show that generic C code can be outperformed by Java but they neglect the fact that the C code can also undergo optimizations. The typical assumption is that gcc is the compiler, which immediately puts the C code at a significant disadvantage. Get a real compiler which allows hinting on aliasing and other things that the Java JIT uses.
Looking at your ridiculous claims:
Java jits REMOVE the array bounds check if they can prove that the index will never be out of bounds
In short, Java *can* be as fast as C if the compiler can prove to itself that the array doesn't go out of bounds. If it can't, then it's slower. My statement remains - the upper bound of Java is optimized C.
why the heck do you think that a linked list traversal in Java MUST be slower than "optimized" C code?
I don't - you're just a failure at english comprehension. I said its upper bound is optimized C performance (where optimized means what the dictionary says it does - that you've made it as efficient as the language allows). This means that it is either slower or equal. I'm even allowing Java the advantage of ignoring JIT time there.
Java has only a few runtime checks. Those take not much time. Often during Jit compiling and Hot Spot optimization those checks can get removed, and are removed. At that stage the code is as efficient as C.
So, my statement is correct. The performance of Java has an upper bound at the performance of C, in the case where all the runtime checks are removed. In the case where they aren't (which you admit is possible) then Java is slower. You see - you're losing your own argument.
Your whole argument chain is not taking into account modern compiler technologies.
Garbage. Your argument is not taking into account modern C compiler technologies, which use everything that Java has available. The fact that I'm comparing optimized C code eliminates any advantage Java has in runtime analysis because optimizing C involves runtime analysis and recoding to suit.
In short, you're the narrow minded bigot here. I'm just stating facts that C allows the programmer much more freedom to optimize the code manually with knowledge that is not able to be represented to a Java JIT compiler.
However, please feel free to continue defeating your own argument with proofs that Java can equal C's optimized performance if the JIT can recognize the conditions as right.
Following your logic I rather would write: There is no excuse for heavy math code such as matrix processing to be faster in C/C++ than in Java. In the absolute worst case, you can simply take the machine code generated from the C/C++ compiler and reproduce better code with the Java JIT. No, you can't. The language restrictions of Java are far more significant than the language restrictions in C. For example, you cannot perform unchecked array access in Java on arbitrary memory. In a very real sense, Java's performance on a given platform has an upper bound at C's performance.
Bottom line: you have to admit that there is an "optimal" code for doing a certain matrix problem (general matrix is different from a diagonal one e.g.). It does absolutely not matter if that optimal code is generated by a C++ compiler or by a Java Jit. There is definitely optimal code, and I am saying that that code will not be able to be produced by a Java JIT compiler because the structure of the java language is unable to deal with it as efficiently as the structure (or absence of structure) that the C language has.
The Java code will probably be more maintainable and less error-prone, but to suggest that it will outperform optimized C code is patently ridiculous.
For general purpose computing Java is as fast as C++, since 4 to 5 years. Even Doom clones and 3D engines are written in Java in our days.... get a clue, go with the time, stop repeating over half a decade old mythes. Java is not as fast as C/C++. It's simply a function of the language. In optimized cases, the speed difference may not be great but Java does have performance penalties defined by the language (garbage collection, checked array access, etc.) that are simply not present in C. You might write a Doom clone, but you sure won't write a F.E.A.R. clone. Take your binders off and realize that the tradeoff for the manageability and elegance of Java is some speed. It's no myth - it's a raw fact.
However, if you still choose to disbelieve me, please post the Java source code you believe will outperform optimized C/C++ code. I'd be fascinated to test it out.
The matrix code in particular (where the majority of our processing time is spent) is far superior in Java than it was in C or C++. If your code is targetted to a specific platform then all that says is your C/C++ coders were idiots. The only case where a jitted language exceeds a natively compiled language is where the JIT compiler can apply optimizations the native code compiler cannot for compatibility reasons (eg avoiding SSE3 when you might run on an older CPU).
There is no excuse for heavy math code such as matrix processing to be faster in Java than C/C++. In the absolute worst case, you can simply take the machine code generated from the Java JIT and reproduce better code in C/C++.
Powerline isn't the best place for an unbiased opinion, but that aside his analysis is very one sided. He's not discussing a point but starting with a conclusion and cherrypicking legal cases - much the same way I did.;)
I won't deny the legal issues are far from settled, but to say that they are all in favor of the NSA is ridiculous. I chose the particular case I mentioned because it's the most recent to deal with the 4th amendment in terms of wiretapping. I think it would be good to see this case end up in the USSC just to settle the issue.
I'm saying it's reasonable to listen to both sides of cross-border conversations in wartime (or even "Authorization for Use of Military Force"-time). lol - I'm not about to quibble over that. The President either has the power to spy or he doesn't. The constitution makes no discernment between "wartime" and "not-wartime" regardless of the way congress framed it. I say it is not reasonable to change your views depending on the times, in fact I think it's more important during wartime to maintain the peacetime values or you risk sliding from a free state to a totalitarian one.
How about just the ones talking to terrorist suspects? How about temporarily, just until the terror threat is eliminated, even though that might be a long time? In that case, I say get a judge to look at it - if it's reasonable then a judge won't knock it back. I think the FISA rules of 3 days after the fact is a pretty good compromise. Realistically, the terrorist threat will never be eliminated, just like crime will never be eliminated and drugs and every other "war" we decide to declare on a noun.
I think we should win the war. I think we should prevent the terrorist attacks from succeeding. I think that the duty to win the war is the number one principle when you're in a war. Because you owe it to the people on your side who'll be killed otherwise. Define "winning the war" because it is impossible to win a "war on terror". Terror happens - internally and externally. It's just criminal activity with a political bent and wiping out terror is about as realistic as wiping out crime. You have to contain it, minimize the future damage and ensure that the criminal threat doesn't change your political beliefs or goals.
Freedoms are more important than life. If you start giving up freedoms just because of threats to safety then you end up with complete government control of the population - the antithesis of what the country was founded on.
If the terrorists succeed again in another large-scale attack, do you think you'll end up with more civil liberties or fewer? How did it work the last time? Fewer, because people (probably not yourself, but in general) are weak and like sacrificing liberty for the illusion of safety and governments capitalize on that fear to broaden their powers. I don't think that's a good reason to give up a philosophy of small governments and general freedoms though, because it's a losing battle - when another attack happens anyway (which it will) do you cede more ground?
Slashdot Mirror
I really don't see a custom "Physics Processor" being a long-lived add-on for the PC platform. It's essentially just another floating point SIMD processor with specialized drivers for game engine physics. With multicore+hyperthreaded CPUs coming out very soon, the physics engines can be offloaded to extra processing units in your system rather than having to fork out money for a card that can only be used for a special purpose.
In addition, there's already a hideously powerful SIMD engine in most gaming systems loosely called "the video card". With the advent of DirectX 10 hardware which lets the card GPU write it's intermediate calculations back to main memory rather than forcing it all out to the frame buffer, a whole bunch of physics processing can suddenly be done through the GPU.
Lastly, the API to talk to these cards is single-vendor and proprietary. That's never been a long term solution for longevity (unless you're Microsoft), so it won't really take off until DirectX 11 or later integrates a DirectPhysics layer to allow multiple hardware vendors to compete without game devs having to write radically different code.
So, between multicore/hyperthreaded CPUs and DirectX10 or better GPUs with a proprietary API to the card... cute hardware but not a long term solution.
Realtime has absolutely nothing to do with the relative speed of the OS or GUI. What it means is that the OS can *guarantee* a response to an input within a defined period of time. While that time is typically very short, you could still technically be realtime if you could demonstrate guaranteed response within 24 hours (though you wouldn't be particularly useful).
Again, technically that's "hard" realtime. "Soft" realtime system are just pretenders that can't really guarantee anything and just look kinda like a preemptive OS with priority levels and the like.
Linux is not a realtime system (without very specific extensions anyway). You don't really want a general purpose OS as "realtime" anyway - it just doesn't help things at all and tends to complicate the processing model.
CE 5.0 (and probably 6.0) are not hard realtime systems. Even at the OEM level (where you can actually write real ISRs) there's no guaranteed response time, just a bunch of realtime looking stuff. At the Application Developer, or even Device Driver level (ISTs, not ISRs) you are so far from realtime it really doesn't make much sense to talk about it in those terms.
If you read between the lines on this report from Microsoft you can glean most of what I've said.
Buggy video drivers would take down NT 3.51 just as fast as NT 4.0. If you'd read my post, you'd notice that the video driver crashing in user mode in 3.51 would bring down csrss.exe which resulted in the machine blue screening anyway.
I dealt with plenty of buggy video drivers in 3.51 and 4.0 and the end result was the same in either case - a blue screen.
Now, you are absolutely correct that a command prompt would have been better than a blue screen, but that's not the way it worked in 3.51 so you can't make a case that moving the GUI to the kernel reduced stability because in either case a bug led to a blue screen.
Granted, but reading it literally certainly implies that NT/XP sat over Windows/DOS. Now that you've expanded on what you meant, I definitely agree that the paradigm was lifted straight from Windows/DOS (or probably more strictly OS/2 1.x, then morphed to Win3.x).
In an interesting followup, I don't think moving the GDI into the kernel was that big of a deal. Most operating systems have done this to some extent and it really didn't affect the stability of NT at all. I read big articles at the time on how terrible it was that the GUI crashing would crash the OS, but guess what - grab your NT 3.51 installation and terminate csrss.exe and see what happens. Blue screen. (This still happens on Vista btw). THAT is bad design, for sure.
Again, interestingly enough, the new GUI drivers are going back the other way with the majority of the driver code being pulled back out to user mode and a small amount being left in the kernel as a conduit to the hardware. A whole bunch of other drivers are now user mode apps (mostly USB and Audio drivers). Interesting the way the wheel spins.
And, I absolutely agree that Windows doesn't stand up to the big commercial Unixes (or non-Unixes for that matter) in terms of stability and reliability. Getting better, but not there.
Are you for real?
This is true of user level applications, but certainly not for system level ones. The stuff in Unix is hideously incompatible across incarnations - try parsing
RSA writes driver level code (to keep their proprietary algorithms sekrut) and hooks it to the Windows GUI logon process - that's something that changes between desktop managers on Unix, let alone versions or even incarnations! There may be pseudo-stable APIs there but there's an awful lot of redundancy and it's not exactly a clean landscape (xdm, kdm, gdm, whateverdm etc.)
Now, I'm not remotely suggesting Windows is any better than Unix in this regard, but the only thing it really does have going for it is there's a lot fewer "versions" out there. Like Unix, the core APIs are very stable. It's the fringe and special purpose stuff you have to worry about.
Note also that the same thing happens to Unix from time to time: shadow passwords broke a bunch of stuff, MD5 hashes broke more stuff, pam broke a whole different set of stuff, etc.
Oh, please! Learn your OS history. NT/XP never sat on top of DOS, Win3.x or Win9x. The original NT design was actually supposed to support multiuser UI sessions out of the box (hence the entire UI being designed around a client/server RPC model) but it didn't end up that way for any number of performance and time-to-market constraints.
The Vista design could best be described as a multiuser kernel that got hacked up to service a single user GUI that looked a lot like the existing single user product that was on the market, which was then moved into the kernel to improve performance, which then got a multiuser terminal layer hacked over the top (using the multiuser not-GUI-part-of-the-kernel that was already there), which then got morphed into "Fast User Switching".
The multiuser UI in Windows XP/Vista is most definitely a hack, but it's got nothing to do with Win3.x or DOS.
As for the original context - (yawn). OS upgrades change APIs. MS has been working on security so their security APIs are going to change. If you tie yourself to MS, then you get to do some work to use their new APIs. Nothing to see here - move along.
Agreed, but when compared to other games (like Everquest) which has the outdoors broken up significantly more granularly then you see where the scalability is hampered.
You're thinking about it the wrong way. It's OO in the sense of stdin and stdout, which are object streams and not character streams.
.NET object has a ToString() method, if the final output actually ends up on the console then ToString() is called and you get a result.
For example, "dir" returns a stream of objects which are of type "File". If you pipe that output into another command then it has the full file information available to it from the object stream, so can act on the file contents, file name, file type, file dates etc if it chooses. Another command "list-users" may output a stream of user objects. Something else may output a stream of some other type of object. etc.
From there, and some "glue" type commands which allow object transformation, property selection and taking of subsets of objects you can build up a fairly powerful command line that looks like a unix shell but is kinda different too when you think of all the metadata going between the commands.
Naturally, as every
Kinda cool. Not sure if it will be more or less useful than the unix model though.
One of the interesting decisions Blizzard made in developing WoW was to do away with the concept of "zoning", which is prevalent in a lot of other MMOGs. This implicitly limited their scalability as games with "zones" typically split the zones over separate physical machines to balance the load to a manageable level. It also allows a degree of network scalability as you can route different zones along different network paths.
In making the entire world effectively zoneless, Blizzard made their scalability a lot more difficult as you no longer have the "neat" option of just tossing a few more machines into the rack, giving them their own dedicated bandwidth and migrating zones from overloaded boxes onto the new ones.
Also, I have to say that catering for the million or so US players (forget how their demographics break down) should have given them a heads up on the need for a whole slew of heavy duty data centers. Like it or not, that's the price you have to pay for a wildly successful game.
Drivers aren't signed until they are tested and certified by Microsoft, right?
No, this isn't the case. You can sign drivers yourself if you have a code signing cert from Verisign and have registered with MS to get a cert signed by them. The manditory signing is only on x64 versions too.
This means "beta" drivers will be signed by their developers and runnable on Vista. The net effect of the code signing is it just raises the bar a little on who can write drivers for the system, and potentially causes headaches for open source drivers like ext2 and winpcap (which is where I see the main problem).
ALERT!
Pentium based machines are also vulnerable to a denial of service attack from a hacker with physical access to the machine and in the possession of a large axe. Should the attacker be wielding a pair of axes (one in each hand) then the attack would constitute a distributed denial of service.
Notes is, by a wide margin, the worst email client I've ever used.
I don't normally do this, but QFT!
Whoa. Whoever tried to sell Exchange into that installation needs to be shot. Like Notes, it's not designed to be an ISP email system. People need to get off the IMAPd vs Exchange kick and realize that they are very different products. No ISP should *ever* look at Exchange for their customers.
In terms of Exchange vs Notes, I just can't get past the past 5 years of absolute misery and horror that Notes has inflicted on me to even fight against Microsoft on this one. IBM needs to just dump Notes and come up with something that can truly compete for user mindshare.
I hope you apply the same zeal to IBM's patent portfolio that you do to Microsoft's, because IBM's library is far bigger.
Microsoft's methods to going into the AS400 market is simple - take what they have and put more and more stuff onto it. Sharepoint, Exchange and SQL Server are doing fairly well so you can expect MS to be leveraging those products to give away just a couple more things until you suddenly find you don't need your AS/400s any more. IBM doesn't help its own cause much there either by shipping full J2EE environments on Windows and AS/400s.
I have no doubts that Notes servers are easier to maintain than Exchange servers btw. I'm just continually in awe at the stupidity of the Notes client interface. If they could get that looking and running as smoothly as Outlook does (yeah, I know, viruses etc.) then I'd be arguing the Notes thing all over the place, but it just hasn't happened and it's really hurting Notes badly.
I agree 100%. IE has ActiveX. Mozilla has plugins. Both are extensibility interfaces that are essential for web browsing. Properly implemented and secured they are a great asset for the end user. Improperly implemented they just become a security or usability nightmare.
I'm not convinced either browser does it well yet but Firefox does seem better than IE.
A hotspot compiler optimizes for situations the hotspot compiler can detect and adapt to.
A human optimizing C code can optimize for all those situations and more.
C optimization is therefore a superset of Java optimization. Whine about it all you like, but that's the fundamental truth.
Thanks for playing, you lose.
Sorry, I have to admit I missed that little word uper bound. In fact it is not nice of you to make a conversation over 3 posts and finally hit me with that into my face.
It's not nice of me to make you miss a word I clearly posted and used? You need to wear more tinfoil on your head so my mind control rays affect you less.
A very simple situation where the C model fails is: compile a program to Pentium code and let it run on a Pentium 4.
Yes - and that is the case that most Java nuts use to "prove" Java is faster than C. However, it's not the case I was arguing. My point is that if you know your target platform then C will be faster or at least as fast as Java because you can compile it to that specific platform.
In the absolute worst case, the argument falls back to the fact the entire JVM is written in C, so I can happily make the argument that C is provably as fast as Java in every situation simply because Java is really executing C code anyway. Yes - it's cheating but it just shows the futility of the Java argument.
C/C++ optimization is not "cool" in the academic community but it's very much alive and still very much an area that companies spend billions of dollars on. A CPU lives and dies by the efficiency of its C compiler. The same cannot be said for JVMs.
You can express every problem in C that you can express in Java. Excluding C libraries is just stupidity, unless you want to exclude java.lang, java.util and all the other stuff from Java as well, which makes the entire language useless.
So, no. Unless you change the bounds of the argument, fully optimized C will always present the upper bound of performance for fully optimized Java when you know the target platform. To suggest anything else is simple ignorance of how computers work.
Just posting in support of the parent. As bad as Microsoft is, I'd happily use Outlook/Exchange over Lotus Notes any day of the week. In fact, I'd rather just go without email altogether than use Lotus Notes. It's seriously the worst end-user email product I've ever had the misfortune to have forced onto my desktop.
Ahh...your typical uninformed slashdot poster...
Not guilty. However, you seem guilty of Java bigotry and failure to read and understand research papers.
You do realize that array bounds checking is eliminated by modern VM's?
Of course, and I've read the paper you linked. Thanks for telling me stuff I know and even recognized in my previous posts by saying that Java has an upper bound at C's optimized performance. *If* the runtime checks can be removed then Java array access is as fast as C. If they can't then Java is slower.
The Java version of Quake performs faster than the C version
The C version was compiled for a 386. Recompile it and optimize it and you'll get a hell of a lot more performance than the original. Do you really think that game developers are all idiots for using C/C++ for their game engines instead of Java? Here's a big smack with the cluestick for you - they use C/C++ because it offers better performance when optimized. When I see a game released under Java then I might give you some credibility but until then you're just another tired old bigot comparing a modern JIT with a C program compiled for a 10 year old processor.
Your other benchmarks are just as telling - they compare Java code with unoptimized C code using the worst possible compiler for performance (gcc). You do realize modern C optimization allows the developer to specify pointer aliasing, efficiently use registers and processor features through intrinsics and other optimizations that the JIT uses in the cases that you demonstrate performance advantages over C/C++ code.
Simply put, the only cases where you demonstrate Java advantages are in comparisons to unoptimized C. If all you have is comparisons using C as a baseline rather than comparisons with optimized C then you're deluding yourself and pitching out the lie that Java *is* as fast as C rather than the truth that Java has an upper bound at optimized C's performance.
Java and Hotspots optimize on the fly. C coders optimize better through runtime analysis and knowing meta-information about the code that a compiler can never hope to know.
I'm not narrow minded, I'm just not a Java bigot like you. The simple fact is you can optimze C code more than you can optimze Java code. All the studies (which I have looked at extensively) show that generic C code can be outperformed by Java but they neglect the fact that the C code can also undergo optimizations. The typical assumption is that gcc is the compiler, which immediately puts the C code at a significant disadvantage. Get a real compiler which allows hinting on aliasing and other things that the Java JIT uses.
Looking at your ridiculous claims:
Java jits REMOVE the array bounds check if they can prove that the index will never be out of bounds
In short, Java *can* be as fast as C if the compiler can prove to itself that the array doesn't go out of bounds. If it can't, then it's slower. My statement remains - the upper bound of Java is optimized C.
why the heck do you think that a linked list traversal in Java MUST be slower than "optimized" C code?
I don't - you're just a failure at english comprehension. I said its upper bound is optimized C performance (where optimized means what the dictionary says it does - that you've made it as efficient as the language allows). This means that it is either slower or equal. I'm even allowing Java the advantage of ignoring JIT time there.
Java has only a few runtime checks. Those take not much time. Often during Jit compiling and Hot Spot optimization those checks can get removed, and are removed. At that stage the code is as efficient as C.
So, my statement is correct. The performance of Java has an upper bound at the performance of C, in the case where all the runtime checks are removed. In the case where they aren't (which you admit is possible) then Java is slower. You see - you're losing your own argument.
Your whole argument chain is not taking into account modern compiler technologies.
Garbage. Your argument is not taking into account modern C compiler technologies, which use everything that Java has available. The fact that I'm comparing optimized C code eliminates any advantage Java has in runtime analysis because optimizing C involves runtime analysis and recoding to suit.
In short, you're the narrow minded bigot here. I'm just stating facts that C allows the programmer much more freedom to optimize the code manually with knowledge that is not able to be represented to a Java JIT compiler.
However, please feel free to continue defeating your own argument with proofs that Java can equal C's optimized performance if the JIT can recognize the conditions as right.
Following your logic I rather would write: There is no excuse for heavy math code such as matrix processing to be faster in C/C++ than in Java. In the absolute worst case, you can simply take the machine code generated from the C/C++ compiler and reproduce better code with the Java JIT.
.... get a clue, go with the time, stop repeating over half a decade old mythes.
No, you can't. The language restrictions of Java are far more significant than the language restrictions in C. For example, you cannot perform unchecked array access in Java on arbitrary memory. In a very real sense, Java's performance on a given platform has an upper bound at C's performance.
Bottom line: you have to admit that there is an "optimal" code for doing a certain matrix problem (general matrix is different from a diagonal one e.g.). It does absolutely not matter if that optimal code is generated by a C++ compiler or by a Java Jit.
There is definitely optimal code, and I am saying that that code will not be able to be produced by a Java JIT compiler because the structure of the java language is unable to deal with it as efficiently as the structure (or absence of structure) that the C language has.
The Java code will probably be more maintainable and less error-prone, but to suggest that it will outperform optimized C code is patently ridiculous.
For general purpose computing Java is as fast as C++, since 4 to 5 years. Even Doom clones and 3D engines are written in Java in our days
Java is not as fast as C/C++. It's simply a function of the language. In optimized cases, the speed difference may not be great but Java does have performance penalties defined by the language (garbage collection, checked array access, etc.) that are simply not present in C. You might write a Doom clone, but you sure won't write a F.E.A.R. clone. Take your binders off and realize that the tradeoff for the manageability and elegance of Java is some speed. It's no myth - it's a raw fact.
However, if you still choose to disbelieve me, please post the Java source code you believe will outperform optimized C/C++ code. I'd be fascinated to test it out.
The matrix code in particular (where the majority of our processing time is spent) is far superior in Java than it was in C or C++.
If your code is targetted to a specific platform then all that says is your C/C++ coders were idiots. The only case where a jitted language exceeds a natively compiled language is where the JIT compiler can apply optimizations the native code compiler cannot for compatibility reasons (eg avoiding SSE3 when you might run on an older CPU).
There is no excuse for heavy math code such as matrix processing to be faster in Java than C/C++. In the absolute worst case, you can simply take the machine code generated from the Java JIT and reproduce better code in C/C++.
Powerline isn't the best place for an unbiased opinion, but that aside his analysis is very one sided. He's not discussing a point but starting with a conclusion and cherrypicking legal cases - much the same way I did. ;)
I won't deny the legal issues are far from settled, but to say that they are all in favor of the NSA is ridiculous. I chose the particular case I mentioned because it's the most recent to deal with the 4th amendment in terms of wiretapping. I think it would be good to see this case end up in the USSC just to settle the issue.
If you want a good alternate opinion on the matter, check out John Dean's column on FindLaw here: http://writ.news.findlaw.com/dean/20060224.html
I'm saying it's reasonable to listen to both sides of cross-border conversations in wartime (or even "Authorization for Use of Military Force"-time).
lol - I'm not about to quibble over that. The President either has the power to spy or he doesn't. The constitution makes no discernment between "wartime" and "not-wartime" regardless of the way congress framed it. I say it is not reasonable to change your views depending on the times, in fact I think it's more important during wartime to maintain the peacetime values or you risk sliding from a free state to a totalitarian one.
How about just the ones talking to terrorist suspects? How about temporarily, just until the terror threat is eliminated, even though that might be a long time?
In that case, I say get a judge to look at it - if it's reasonable then a judge won't knock it back. I think the FISA rules of 3 days after the fact is a pretty good compromise. Realistically, the terrorist threat will never be eliminated, just like crime will never be eliminated and drugs and every other "war" we decide to declare on a noun.
I think we should win the war. I think we should prevent the terrorist attacks from succeeding. I think that the duty to win the war is the number one principle when you're in a war. Because you owe it to the people on your side who'll be killed otherwise.
Define "winning the war" because it is impossible to win a "war on terror". Terror happens - internally and externally. It's just criminal activity with a political bent and wiping out terror is about as realistic as wiping out crime. You have to contain it, minimize the future damage and ensure that the criminal threat doesn't change your political beliefs or goals.
Freedoms are more important than life. If you start giving up freedoms just because of threats to safety then you end up with complete government control of the population - the antithesis of what the country was founded on.
If the terrorists succeed again in another large-scale attack, do you think you'll end up with more civil liberties or fewer? How did it work the last time?
Fewer, because people (probably not yourself, but in general) are weak and like sacrificing liberty for the illusion of safety and governments capitalize on that fear to broaden their powers. I don't think that's a good reason to give up a philosophy of small governments and general freedoms though, because it's a losing battle - when another attack happens anyway (which it will) do you cede more ground?