Actually, games are the finset pieces of engineering on the face of computing. The evangalist behind DirectX (Alex St. John) once said something along the lines of "its incredible that software these days can visibly refresh drawing just a few graphics on the screen while id is spraying huge worlds with tons of AI driven monsters on the screen at 30fps.) This quote holds very true. Games tend t spend a lot of time working on precise algorithms for all the performance critical sections, and games tend to be written to use as little memory as possible. Thus, most people understand why the requirements for games are so high, you're trying to emulate reality for god's sake! If KDE was written by a game designer, it would use 4 megs of RAM, be able to redraw a browser window at 200fps, and would load in less than a second.
Maya won't do much for game development. Historically, the premier game development platforms have been 3D Studio MAX and Softimage. Maya is more used for 3D animations and such, rarely for game modeling.
Not, that is a very UNIX-ism. The sheer fact that applications even load libraries by filename is a stupid idea pioneered by those crazy UNIX weenies. (As you can see, I'm slightly inflamed for having to make a zillion symlinks to install the NVIDIA OpenGL drivers.)
I doubt they care. Only porting to one version of the OS is something that these companies often do. For example, SoftImage even has a list of cards that they certify to work with it. They won't gaurantee that it will work on other cards. When you're laying down $10K for a product, most people just go out and buy a machine custom made for that product.
No, people buy $10000 maya to put on their $7000 (the price of a high end Visual Workstation) NT workstations. The Intergraph WildCat series is that fastest 3D hardware available on PCs. It outperforms SGI's VisualPC hardware by 126% (according to a MaximumPC review) in awadvs (a viewperf test) In real world rendering, the Intergraph machine could handle complex scenes in MAX that the SGI simply choked on. If you look at the tests on intergraph's website, you'll see that the WildCat consistantly outperforms the Quadro based Elsa card by 40-100% plus has 256 meg of memory, a number even the new SGI VPro cards can't touch. Even Carmack loves Intergraph. Second, Intergraph seems to be doing quite well. Since when did they sell off to 3D Labs? Third, I agree that SGI and the ARB have to get off their ass. Direct3D is coming and seriously whopping OpenGL in terms of core features (and soon speed. Direct3D 7 comes close and D3D 8 may just go over the top.) However, my point wasn't about that. The VisualWorkstations failed at the high end and midrange of the NT workstation market. Maya is definately a high-end product, but as it stands, the supporting technology around a Linux-based SGI machine would be mid-range to low end. (GIMP in place of Photoshop, not as many high-end support tools, lower power hardware, etc.)
Of course, you know why this is being ported. As last I remember, Alias|Wavefront is a subsidary of SGI, and this is yet another cog in SGIs plan to take over the world:) Seriously though, the whole thing seems to fit together now. SGI is losing money. Their UNIX business isn't doing terribly well. They tried to get into the NT workstation arena, but got whipped by vendors such as Intergraph. (Nothing beats a WildCat.) However, now SGI is trying to get back into the market with cheaper Linux based machines. By using NVIDIA as their graphics supplier (that's they only reason NVIDIA ported their drivers) they can make a Linux based product to compete with the NT machines. Now, they can get Maya on it to complete the solution. However, I see a major problem. SGI's performance still isn't that good. The reason why the Visual Workstation line didn't do so well was not because of NT (which is a damn good OS for 3D stuff) but because the hardware kind of sucked. It was relativly expensive, the memory was propriotary (and expensive), and the performance didn't come close to that of Intergraph's machines. (In some test the Cobalt chipset's performance was less than half that of the OLD WildCat 4110) The new NVIDIA chips aren't that much faster (GeForce class, check www.intergraph.com for benchmarks.) That's why I think that this Maya port is sort of futile. If they were selling a lower-end 3D package, I could probably understand them using Linux and NVIDIA chips as a mid-range to low-end solution. However, Maya costs around $10,000 and at that price-level, most people can afford a REALLY fast Intergraph machine. Not to mention that more support tools exist around NT (Photoshop and such) than do on Linux.
Actually that is VERY false. The reason Tom seems biased is because NVIDIA kicks ass. If you read MaximumPC (maybe it was back around the boot issues though) Somebody responded saying that the nVIDIA approved logo was NOT that NVIDIA agreed with the reviews, but was program started by Tom to try to show readers that his testing methods were approved by major hardware companies. He was trying to show that this wasn't just some kid's website, but a real site with corporate approval. He tried to get "seals of approval" for his testing methods from companies like Matrox, ATI, NVIDIA, S3, etc, but NVIDIA was the one who did it first. Unfortuneatly the situation backfired because aften NVIDIA put their seal, ATI and the other refused to give their seals because of politics.
I just tried to install this on a 386 with 4 megs of RAM. It wouldn't work! Then I installed Tiny Linux and it worked fine! Caldera sucks! >>>>>>> To tell the truth, you're personal experience has very little bearing on the suckiness rating of anything.
An interface that doesn't change results in what we have in UNIX now. Multiple libraries. The reason that I have to run two versions of glibc is because UNIX is designed through that model, and anytime the interface NEEDs to change (ie. stuff that evolves like DirectX) you have to fork the entire friggin library. If glibc was COM based, then you could simply write the new version of the library, and expose a glibc2 interface. Then, write a glibc1 interface that uses mostly the new code, except where the interface is different. If DirectX used this model, you'd end up with nearly 80meg of incompatible DirectX libraries. In the end, libraries really SHOULD be object based unless they're so small that they won't evolve. If the KDE-libs had been COM based, then you simply could add another interface for compatibility while maintaining the same based code. This works even better in an OS interface. Prevents DoThisEXT and DoThis2 type crap. As for COM, I'll tell you,it might not gaurantee compatibility, but it sure as hell delivers in practice. The fact that a large library like DirecX can be changed so often, yet retain full backwards compatibility without being overtly huge is a testament to the COM way of doing things. Multiple glibcs, kdelibs, and libstdc++s are an example of the way NOT to do things.
It's called COM. Take DirectX. Now in its 8th major revision, the library has almost been rewritten, but still maintains backwards compatibility without sacrificing size and speed. The problem with UNIX, though, is not that. Its the numerous, incompatible libraries that do the same thing.
The reason why Quake doesn't look like Toy Story? You're CPU can't push nearly enough triangles. The GeForce can still razterize more triangles than you can throw at it. Resolution is a different issue entierly, since the load on the CPU doesn't change. The test you mention is invalid in this arguement because the fact that a GeForce isn't being maxed out at lower resolutions (ie. it gets faster from Celeron to PIII) means that the proc isn't giving the GeForce enough triangles to render. If you increased the proc speed to say 2 GHz, then the test would be faster still at lower resolutions. I know it's confusing. In the end, its a chain issue. The total speed is as weak as the weakest link. At 1024x768, above which the gains become smaller at this polygon size, the Geforce can still handle more polygons that the PIII 1GHz can feed it. Right now, the proc is the weakest link.) A more valid benchmark would be this. Use a high polycount scene and compare differnt procs. NVIDIA as already shown this. Scenes that bog down even on a 1GHz Pentium III, run fine on a GeForce2 because of the geometry acceleration. The key to making games look better is more triangles, and current CPUs can't nearly push the cards hard enough in that respect.
Hi. I'm the nimrod. My name is Mike. >>>> NimrodS, I meant to write nimrods.
My question was on how to feed this thing, both with memory and I/O. You can add RAM to eliminate disk I/O, but even the RAM is slow compared to the processor core. >>>> You don't NEED to feed this thing. Some computations are simply NOT memory bound. Take Quake 3 for example. Few people will doubt that it is a VERY demanding application. However, it uses less than 25% of the available bandwidth of PC100 SDRAM.
What does a Xeon have - 4MB of L2 cache running at processor core speed? What's that equivalent to - a 4 minute MP3 at a low bit rate? What about the player and the OS? It's getting kind of tight in the cache. >>>>> The Xeon is a server machine. Those use big caches because serving is a cache intensive task. You don't use a Xeon to play an MP3. But take MP3 decode for example. You read a chunk of data into the cache, then run the decode intructions. Those decode instructions take a lot longer than loading the data. MPEG compression is an even better example. Most MPEG algorithms use a 40 X 24 pixel block while doing motion estimation. That 40X24 pixel block easily fits into cache, and the instructions to process that block take a LOT longer than just reading that block.
On a big machine maybe I can have 8MB or 16MB of L2 cache. Ok, now that is enough to fit a good size scanned picture. That pales in comparison to the index of a good sized DB. If a server can have a main memory of 40GB or more, then what's a 16MB cache? A drop... >>>>>>> This isn't a database. I just said that databases don't need faster procs, but faster memory.
MS Outlook shouldn't need 1 Ghz processor. Win2K shouldn't either. Enough said. >>> Agreed.
Scientific problems where the data sets are small. I can't think of any. Most problems worth solving have huge datasets. >>>> I can imagine, though I can't think of one, admitadly, a scientific prob. with a small dataset. maybe tracking particle interactions or something.
Image processing - a reasonable static image can overwhelm a modern cache easily. Video is even more rediculous. At least with scientific programming and image processing you can try to predict the data you'll need next and prefetch. >>> You don't have to load the whole image. Take many of the filters in Photoshop (like lighten or blur.) They load a chunk of the image (which fits into cache) into a matrix, then do a LOT of operations on that chunk. Memory bandwidth is not really important here.
This is like dropping a great engine in a crappy car. It will idle really nicely, but the suspension and the steering won't let you go fast around corners. I don't care what the redline of the engine is - I want to know how fast the vehicle goes. Processors are far ahead of memory and I/O technology - you'd have a much more useful system if this was balanced better. >>>>>>>>>>> But what if you're drag racing?
The point you don't seem to understand, is that a lot of apps simply don't NEED memory bandwidth. right now, my 3D renderer is starved for RAM, but the RAM is easily fast enough to support it. Or something like Quake or video compression/decompression, where many instructions are done on a small amount of data. When transforming a polygon, two matrixs are multiplied. Though it is just a loading of 20 numbers, it results in 16 multiplies (which take a lot longer than a load) and 12 adds. Or perspective division, which results in a (very slow) division instruction from loading only one vertex. Or in image or video (or even sound) processing, where many operations are applied to small chunks of data.
The suckiness or non-suckiness of UNIX all depends on what you're using for. Given that Miguel comes from GNOME, inherently a desktop project, it is understandable that he isn't to fond of UNIX, because for those tasks, it DOES suck. The problems he pointed out have long ago been addressed by COM, OLE, OpenDOC, etc. on other platforms. The desktop user and the traditional UNIX user are inherently quite different. Desktop users often use a series of different appliactions, all upgraged often, and all interoperating with each other. Desktop OSs, like Windows and Mac, and OS/2, were designed with these needs in mind. However, UNIX was designed for a radically different purpose. Lets look at the design environment of UNIX. It was used originally at the Bell labs think tank, where people used it to work on their own projects. These people didn't have a spate of appliactions to work with, they used UNIX as a standard platform for their own projects. Thus the high degree of flexibility and personal "sculptability" that UNIX enjoys. Later, UNIX found use in custom solutions such as in AT&T's network. Further still, people designing back-end servers found that the fact that UNIX ran a single application (or a tightly interwound team of applications) well for months on end made it perfect for server tasks. The "traditional" uses of UNIX all have this in comment. However, as I already stated, desktop uses are quite different. These days you have games, word processors, web-browsers, art programs, audio programs, etc, that are all used on the same system, and all have to share resources. In the traditional UNIX environment, you could get away with the multitude of libraries that the applications needed, because you were often running one fixed set of applications. However, that same method applied to the desktop user reeks havoc. This is why I complain that I have dozens of libraries on my system. Along with two glibc and libstdc++s, I have two Qts,and KDEs, one gtk+ and gnome-libs, tcl, tk, and numerous other support libraries. Problematically, I have to use them all AT THE SAME TIME. My audio programs use TK, I use KDE2, but KDevelop uses KDE1, and GIMP uses GTK. In the traditional UNIX environment that was fine. You used the machine for software devel, and you ran only one set of libs, because your apps didn't need other ones. So, UNIX does suck in ways. Though the Linux community has done an admirable job making it competitive with Windows, the design is still flawed (for desktop use.) The sheer bloat of the software is the only clue you need. What should be quite a thin, light system (after all, Linux is a fairly selvte kernel) becomes a system nearly as bloated as Win2K! However, that's just a side effect of trying to shoe-horn UNIX into something it wasn't designed to do. That said, UNIX doesn't suck. BeOS couldn't server my little brother's web-page, but that doesn't mean it doesn't suck. It simply wasn't designed to do that.
Great joke, except not. If I made the same comment of Netscape on Linux, I'm afraid I would have gotten quite a few remarks telling me where to put my CPU.
Can we stop the nimrod who say 1GHz is wasted because of limits in memory and I/O technology? The speed is only wasted IF you're doing certian types of tasks. In every other case, it is not. Places where proc speed is wasted: - Serving. - Databases. - Programming/Compiling. Places where it definately is NOT wasted. - Gaming. - 3D rendering. - Running high load apps like 3D Studio, Maya, and MS Outlook. - Running Win2K. - Scientific probs. where the data-sets are fairly small. - Image processing.
In these types of tasks, I/O bandwidth is a non-issue, because if you're 3D renderer is swaping, you're wasted anyway. Machines for these tasks tend to have a load of RAM, thus disk I/O really isn't a factor. For stuff like games (and the little preview window in you're 3D app) the data sets are small, and the computations are large. Even a complex game like Quake3 rarely pushes over 200MB/sec of bandwidth to RAM. That's one reason why RDRAM is often useless, because apps rarely push even the 800MB/sec of SDRAM.
Really? I always though Novell backed up because nobody used IPX. IPX does have it's problems. Its harder to route for one. But it is just FASTER than TCP. I have a DSL connection, and it still takes ages for a transfer to get up to the full speed. (No, not on BeOS's cruddy TCP, NTs not so cruddy TCP). Also, over my local LAN, IPX beats TCP/IP hands down. And this is on NT, which is designed for TCP.
Too bad IP doesn't have connections. It's a stateless, unreliable, unsequenced datagram protocol. I'll cut you some slack -- maybe you meant TCP? Well, true, it does have some overhead, but that's the price you pay for building a reliable data stream protocol on top of an unreliable, packeted-based protocol. I'd like to see you do a better job. >>>>>>> Sorry, my faux pas, I was referring to TCP/IP, (and I thought the orignal poster was too. You see, you don't see IP mentioned often by itself.)
The US Department of Defense.
If you're also wondering why, it's because IP does a damn good job given the constraints it has and had to work with. Again, I'd like to see you do a better job. >>>>> I couldn't do a better job. But other people have. My point was that even though IP is not the best protocol we still use it.
HTTP is also pretty limited. Read the/. article on what they're trying to replace it with.
You mean BXXP? Which is basically TCP layered on top of TCP? And you're complaining about the overhead of TCP? Um, hello, McFly? Anyone home? >>>>> Again I was just pointing out that HTTP also is a fairly limited standard. I wasn't trying to promot BXXP in any way.
If you really don't care about all this stuff, why the hell are you posting about it? This is the thing that really gives you away as a troll. Never, ever admit you're not interested in the subject matter, or the whole gig is up. >>>>>>> Let's see, do YOU care about the protocol your email system uses? TCP pisses me off, but POP3 could be made by MS and still not bug me.
X11 has been around for how many years? Meanwhile, this is the third or fourth major iteration of the Macintosh graphics interface? Riiight. >>>>>> How often has X crashed on you? It IS possible to design a stable system the first time around, especially if it is a clean design. Still its a moot point. Aqua isn't out yet, so you can't comment on the stability.
However, it is a lot faster and more powerful.
I don't really expect Aqua to be much faster then X11. Perhaps slightly so, simply because it is more limited. But not significantly so.
As far as power goes, you're dead wrong. Extensibility, network transparency, host, machine, and transport independence are just a few of the things X11 has that Mac OS X's graphics system doesn't. >>>> Fast? I'd like to see X do those transparency tricks with any modicum of speed. As for power, it depends on your definition. In my eyes, the DPDF and imaging features make for a much more powerful system than simply network transparency. You think anyone uses OpenGL JUST because of the network transparency?
I don't own an IBM mainframe or a Palm Pilot.
No shit? Like that makes a whole hell of a lot of difference to my argument. The point was, X11 will go with you no matter where you go, not that you could run it on the IBM S/390 you have in your bedroom. >>>> I was kidding. I understand your point, but in truth. How many Mac users interact with anything other than Windows PCs? The question is one of the relevance of features. If Aqua had network transparency, it would just go unused. These days, the vast majority of Mac users are home users and graphics artists. The former rarely have *NIX machines, and the latter usually have powerful client machines, rather than a large back-end server. And even if they did, the PP doesn't have an X server.
I've seen one for it, so you're wrong yet again. >>>>> You're kidding right? My only question is, what the hell? I mean I can understand one for a WinCE HPC, but for the palm pilot?
Actually, the OP and you are both talking out of your ass, because Aqua is really the UI layer, not the graphics layer like X11 is. It's comparing apples to oranges. The point I was trying to make was that standards are a good thing, which you've missed entirely. Instead, and as usual, you've tried to divert the discussion to a flamewar of Unix vs this mythical "desktop OS" you always bring up. >>>>>>>> Personal vandetta maybe? My point is that your argueing symantics. What does Aqua mean? Technically yes, it means just the UI layer of MacOSX. In practice, it means the whole enchillada, DPDF and all. This is a comparison between the entire MacOSX display system and X11. And that is a very valid comparison. And where, praytell, did I bring in a mythical "desktop OS?" (BTW> Did you get the apples vs. oranges pun?)
But, let's indulge you. X11 vs Win9X GDI. At least you got the layers right for that one. The GDI is encumbered with backwards compatability with years worth of things that don't exist anymore. It's tied to Windows. It's tied to the Intel platform. The API changes with each major release of the OS. It's poorly and often incorrectly documented. It's propriatary. It's a pain in the ass to work with. It's limited to a single user on a single machine. In short, it's crap >>>>>>> Let's indulge you. X11. It's limited by years worth of backwards compatibility. It's limited by things that almost don't exist anymore (like low power clients), it's hard to program for, the API changes with every major release of X:) In desktop space, the comments about Intel, Windows, and multi-user don't matter, because everybody runs winte (which are all single user machines). (Statistically of course.) GDI has some additional things going for it though. Much better font handling for one. It's noticably faster (why shouldn't it be, it's in the bloody kernel!) It has and API that is just slightly more complex than X's but has more imaging features. This is the stuff that matters in desktop space. Imaging features and speed. GDI just one-ups X in this respect.
I do know BeOS, but it had nothing to do with this post. BeOS uses neither X nor GDI. However, I've programmed GDI for awhile now, and it surprises me to see that people who promote X, just don't get the fact that the features that make it so great on *NIX (maturity, extensibility, network transparency, flexibility) just don't matter in consumer-space.
Okay, we've already got Mach OSSed. We've got FreeBSD OSSed. Now all we need is some one to make a good Aqua clone (DPDF and all that good stuff, not a theme) and I can ditch this blasted Linux box.
Slashdot Mirror
Actually, games are the finset pieces of engineering on the face of computing. The evangalist behind DirectX (Alex St. John) once said something along the lines of "its incredible that software these days can visibly refresh drawing just a few graphics on the screen while id is spraying huge worlds with tons of AI driven monsters on the screen at 30fps.) This quote holds very true. Games tend t spend a lot of time working on precise algorithms for all the performance critical sections, and games tend to be written to use as little memory as possible. Thus, most people understand why the requirements for games are so high, you're trying to emulate reality for god's sake! If KDE was written by a game designer, it would use 4 megs of RAM, be able to redraw a browser window at 200fps, and would load in less than a second.
Maya won't do much for game development. Historically, the premier game development platforms have been 3D Studio MAX and Softimage. Maya is more used for 3D animations and such, rarely for game modeling.
Not, that is a very UNIX-ism. The sheer fact that applications even load libraries by filename is a stupid idea pioneered by those crazy UNIX weenies. (As you can see, I'm slightly inflamed for having to make a zillion symlinks to install the NVIDIA OpenGL drivers.)
Yea, the whole desktop will look ugly;)
I doubt they care. Only porting to one version of the OS is something that these companies often do. For example, SoftImage even has a list of cards that they certify to work with it. They won't gaurantee that it will work on other cards. When you're laying down $10K for a product, most people just go out and buy a machine custom made for that product.
Wrong. More moons were disovered during the Voyager missions in the '70s.
yasb-frirwwthsgtiadko2. Sounds like some linux software package.
No, people buy $10000 maya to put on their $7000 (the price of a high end Visual Workstation) NT workstations. The Intergraph WildCat series is that fastest 3D hardware available on PCs. It outperforms SGI's VisualPC hardware by 126% (according to a MaximumPC review) in awadvs (a viewperf test) In real world rendering, the Intergraph machine could handle complex scenes in MAX that the SGI simply choked on. If you look at the tests on intergraph's website, you'll see that the WildCat consistantly outperforms the Quadro based Elsa card by 40-100% plus has 256 meg of memory, a number even the new SGI VPro cards can't touch. Even Carmack loves Intergraph. Second, Intergraph seems to be doing quite well. Since when did they sell off to 3D Labs? Third, I agree that SGI and the ARB have to get off their ass. Direct3D is coming and seriously whopping OpenGL in terms of core features (and soon speed. Direct3D 7 comes close and D3D 8 may just go over the top.) However, my point wasn't about that. The VisualWorkstations failed at the high end and midrange of the NT workstation market. Maya is definately a high-end product, but as it stands, the supporting technology around a Linux-based SGI machine would be mid-range to low end. (GIMP in place of Photoshop, not as many high-end support tools, lower power hardware, etc.)
Of course, you know why this is being ported. As last I remember, Alias|Wavefront is a subsidary of SGI, and this is yet another cog in SGIs plan to take over the world :) Seriously though, the whole thing seems to fit together now. SGI is losing money. Their UNIX business isn't doing terribly well. They tried to get into the NT workstation arena, but got whipped by vendors such as Intergraph. (Nothing beats a WildCat.) However, now SGI is trying to get back into the market with cheaper Linux based machines. By using NVIDIA as their graphics supplier (that's they only reason NVIDIA ported their drivers) they can make a Linux based product to compete with the NT machines. Now, they can get Maya on it to complete the solution. However, I see a major problem. SGI's performance still isn't that good. The reason why the Visual Workstation line didn't do so well was not because of NT (which is a damn good OS for 3D stuff) but because the hardware kind of sucked. It was relativly expensive, the memory was propriotary (and expensive), and the performance didn't come close to that of Intergraph's machines. (In some test the Cobalt chipset's performance was less than half that of the OLD WildCat 4110) The new NVIDIA chips aren't that much faster (GeForce class, check www.intergraph.com for benchmarks.) That's why I think that this Maya port is sort of futile. If they were selling a lower-end 3D package, I could probably understand them using Linux and NVIDIA chips as a mid-range to low-end solution. However, Maya costs around $10,000 and at that price-level, most people can afford a REALLY fast Intergraph machine. Not to mention that more support tools exist around NT (Photoshop and such) than do on Linux.
Actually that is VERY false. The reason Tom seems biased is because NVIDIA kicks ass. If you read MaximumPC (maybe it was back around the boot issues though) Somebody responded saying that the nVIDIA approved logo was NOT that NVIDIA agreed with the reviews, but was program started by Tom to try to show readers that his testing methods were approved by major hardware companies. He was trying to show that this wasn't just some kid's website, but a real site with corporate approval. He tried to get "seals of approval" for his testing methods from companies like Matrox, ATI, NVIDIA, S3, etc, but NVIDIA was the one who did it first. Unfortuneatly the situation backfired because aften NVIDIA put their seal, ATI and the other refused to give their seals because of politics.
I just tried to install this on a 386 with 4 megs of RAM. It wouldn't work! Then I installed Tiny Linux and it worked fine! Caldera sucks!
>>>>>>>
To tell the truth, you're personal experience has very little bearing on the suckiness rating of anything.
That frisky little puppy needs a diet.
An interface that doesn't change results in what we have in UNIX now. Multiple libraries. The reason that I have to run two versions of glibc is because UNIX is designed through that model, and anytime the interface NEEDs to change (ie. stuff that evolves like DirectX) you have to fork the entire friggin library. If glibc was COM based, then you could simply write the new version of the library, and expose a glibc2 interface. Then, write a glibc1 interface that uses mostly the new code, except where the interface is different. If DirectX used this model, you'd end up with nearly 80meg of incompatible DirectX libraries. In the end, libraries really SHOULD be object based unless they're so small that they won't evolve. If the KDE-libs had been COM based, then you simply could add another interface for compatibility while maintaining the same based code. This works even better in an OS interface. Prevents DoThisEXT and DoThis2 type crap. As for COM, I'll tell you ,it might not gaurantee compatibility, but it sure as hell delivers in practice. The fact that a large library like DirecX can be changed so often, yet retain full backwards compatibility without being overtly huge is a testament to the COM way of doing things. Multiple glibcs, kdelibs, and libstdc++s are an example of the way NOT to do things.
It's called COM. Take DirectX. Now in its 8th major revision, the library has almost been rewritten, but still maintains backwards compatibility without sacrificing size and speed. The problem with UNIX, though, is not that. Its the numerous, incompatible libraries that do the same thing.
The reason why Quake doesn't look like Toy Story? You're CPU can't push nearly enough triangles. The GeForce can still razterize more triangles than you can throw at it. Resolution is a different issue entierly, since the load on the CPU doesn't change. The test you mention is invalid in this arguement because the fact that a GeForce isn't being maxed out at lower resolutions (ie. it gets faster from Celeron to PIII) means that the proc isn't giving the GeForce enough triangles to render. If you increased the proc speed to say 2 GHz, then the test would be faster still at lower resolutions. I know it's confusing. In the end, its a chain issue. The total speed is as weak as the weakest link. At 1024x768, above which the gains become smaller at this polygon size, the Geforce can still handle more polygons that the PIII 1GHz can feed it. Right now, the proc is the weakest link.) A more valid benchmark would be this. Use a high polycount scene and compare differnt procs. NVIDIA as already shown this. Scenes that bog down even on a 1GHz Pentium III, run fine on a GeForce2 because of the geometry acceleration. The key to making games look better is more triangles, and current CPUs can't nearly push the cards hard enough in that respect.
Hi. I'm the nimrod. My name is Mike.
...
>>>>
NimrodS, I meant to write nimrods.
My question was on how to feed this thing, both with memory and I/O. You can add RAM to eliminate disk I/O, but even the RAM is slow compared to the processor core.
>>>>
You don't NEED to feed this thing. Some computations are simply NOT memory bound. Take Quake 3 for example. Few people will doubt that it is a VERY demanding application. However, it uses less than 25% of the available bandwidth of PC100 SDRAM.
What does a Xeon have - 4MB of L2 cache running at processor core speed? What's that equivalent to - a 4 minute MP3 at a low bit rate? What about the player and the OS? It's getting kind of tight in the cache.
>>>>>
The Xeon is a server machine. Those use big caches because serving is a cache intensive task.
You don't use a Xeon to play an MP3. But take MP3 decode for example. You read a chunk of data into the cache, then run the decode intructions. Those decode instructions take a lot longer than loading the data. MPEG compression is an even better example. Most MPEG algorithms use a 40 X 24 pixel block while doing motion estimation. That 40X24 pixel block easily fits into cache, and the instructions to process that block take a LOT longer than just reading that block.
On a big machine maybe I can have 8MB or 16MB of L2 cache. Ok, now that is enough to fit a good size scanned picture. That pales in comparison to the index of a good sized DB. If a server can have a main memory of 40GB or more, then what's a 16MB cache? A drop
>>>>>>>
This isn't a database. I just said that databases don't need faster procs, but faster memory.
MS Outlook shouldn't need 1 Ghz processor. Win2K shouldn't either. Enough said.
>>>
Agreed.
Scientific problems where the data sets are small. I can't think of any. Most problems worth solving have huge datasets.
>>>>
I can imagine, though I can't think of one, admitadly, a scientific prob. with a small dataset. maybe tracking particle interactions or something.
Image processing - a reasonable static image can overwhelm a modern cache easily. Video is even more rediculous. At least with scientific programming and image processing you can try to predict the data you'll need next and prefetch.
>>>
You don't have to load the whole image. Take many of the filters in Photoshop (like lighten or blur.) They load a chunk of the image (which fits into cache) into a matrix, then do a LOT of operations on that chunk. Memory bandwidth is not really important here.
This is like dropping a great engine in a crappy car. It will idle really nicely, but the suspension and the steering won't let you go fast around corners. I don't care what the redline of the engine is - I want to know how fast the vehicle goes. Processors are far ahead of memory and I/O technology - you'd have a much more useful system if this was balanced better.
>>>>>>>>>>>
But what if you're drag racing?
The point you don't seem to understand, is that a lot of apps simply don't NEED memory bandwidth. right now, my 3D renderer is starved for RAM, but the RAM is easily fast enough to support it. Or something like Quake or video compression/decompression, where many instructions are done on a small amount of data. When transforming a polygon, two matrixs are multiplied. Though it is just a loading of 20 numbers, it results in 16 multiplies (which take a lot longer than a load) and 12 adds. Or perspective division, which results in a (very slow) division instruction from loading only one vertex. Or in image or video (or even sound) processing, where many operations are applied to small chunks of data.
The suckiness or non-suckiness of UNIX all depends on what you're using for. Given that Miguel comes from GNOME, inherently a desktop project, it is understandable that he isn't to fond of UNIX, because for those tasks, it DOES suck. The problems he pointed out have long ago been addressed by COM, OLE, OpenDOC, etc. on other platforms. The desktop user and the traditional UNIX user are inherently quite different. Desktop users often use a series of different appliactions, all upgraged often, and all interoperating with each other. Desktop OSs, like Windows and Mac, and OS/2, were designed with these needs in mind. However, UNIX was designed for a radically different purpose. Lets look at the design environment of UNIX. It was used originally at the Bell labs think tank, where people used it to work on their own projects. These people didn't have a spate of appliactions to work with, they used UNIX as a standard platform for their own projects. Thus the high degree of flexibility and personal "sculptability" that UNIX enjoys. Later, UNIX found use in custom solutions such as in AT&T's network. Further still, people designing back-end servers found that the fact that UNIX ran a single application (or a tightly interwound team of applications) well for months on end made it perfect for server tasks. The "traditional" uses of UNIX all have this in comment. However, as I already stated, desktop uses are quite different. These days you have games, word processors, web-browsers, art programs, audio programs, etc, that are all used on the same system, and all have to share resources. In the traditional UNIX environment, you could get away with the multitude of libraries that the applications needed, because you were often running one fixed set of applications. However, that same method applied to the desktop user reeks havoc. This is why I complain that I have dozens of libraries on my system. Along with two glibc and libstdc++s, I have two Qts,and KDEs, one gtk+ and gnome-libs, tcl, tk, and numerous other support libraries. Problematically, I have to use them all AT THE SAME TIME. My audio programs use TK, I use KDE2, but KDevelop uses KDE1, and GIMP uses GTK. In the traditional UNIX environment that was fine. You used the machine for software devel, and you ran only one set of libs, because your apps didn't need other ones. So, UNIX does suck in ways. Though the Linux community has done an admirable job making it competitive with Windows, the design is still flawed (for desktop use.) The sheer bloat of the software is the only clue you need. What should be quite a thin, light system (after all, Linux is a fairly selvte kernel) becomes a system nearly as bloated as Win2K! However, that's just a side effect of trying to shoe-horn UNIX into something it wasn't designed to do. That said, UNIX doesn't suck. BeOS couldn't server my little brother's web-page, but that doesn't mean it doesn't suck. It simply wasn't designed to do that.
Great joke, except not. If I made the same comment of Netscape on Linux, I'm afraid I would have gotten quite a few remarks telling me where to put my CPU.
Can we stop the nimrod who say 1GHz is wasted because of limits in memory and I/O technology? The speed is only wasted IF you're doing certian types of tasks. In every other case, it is not.
Places where proc speed is wasted:
- Serving.
- Databases.
- Programming/Compiling.
Places where it definately is NOT wasted.
- Gaming.
- 3D rendering.
- Running high load apps like 3D Studio, Maya, and MS Outlook.
- Running Win2K.
- Scientific probs. where the data-sets are fairly small.
- Image processing.
In these types of tasks, I/O bandwidth is a non-issue, because if you're 3D renderer is swaping, you're wasted anyway. Machines for these tasks tend to have a load of RAM, thus disk I/O really isn't a factor. For stuff like games (and the little preview window in you're 3D app) the data sets are small, and the computations are large. Even a complex game like Quake3 rarely pushes over 200MB/sec of bandwidth to RAM. That's one reason why RDRAM is often useless, because apps rarely push even the 800MB/sec of SDRAM.
Can you imagine if Intel had continued with their scheme of releaseing procs with half a bin more speed? How funny would a Pentium 1.066 GHz be?
Really? I always though Novell backed up because nobody used IPX.
IPX does have it's problems. Its harder to route for one. But it is just FASTER than TCP. I have a DSL connection, and it still takes ages for a transfer to get up to the full speed. (No, not on BeOS's cruddy TCP, NTs not so cruddy TCP).
Also, over my local LAN, IPX beats TCP/IP hands down. And this is on NT, which is designed for TCP.
Too bad IP doesn't have connections. It's a stateless, unreliable, unsequenced datagram protocol. I'll cut you some slack -- maybe you meant TCP? Well, true, it does have some overhead, but that's the price you pay for building a reliable data stream protocol on top of an unreliable, packeted-based protocol. I'd like to see you do a better job.
/. article on what they're trying to replace it with.
:) In desktop space, the comments about Intel, Windows, and multi-user don't matter, because everybody runs winte (which are all single user machines). (Statistically of course.) GDI has some additional things going for it though. Much
>>>>>>>
Sorry, my faux pas, I was referring to TCP/IP, (and I thought the orignal poster was too. You see, you don't see IP mentioned often by itself.)
The US Department of Defense.
If you're also wondering why, it's because IP does a damn good job given the constraints it has and had to work with. Again, I'd like to see you do a better job.
>>>>>
I couldn't do a better job. But other people have. My point was that even though IP is not the best protocol we still use it.
HTTP is also pretty limited. Read the
You mean BXXP? Which is basically TCP layered on top of TCP? And you're complaining about the overhead of TCP? Um, hello, McFly? Anyone home?
>>>>>
Again I was just pointing out that HTTP also is a fairly limited standard. I wasn't trying to promot BXXP in any way.
If you really don't care about all this stuff, why the hell are you posting about it? This is the thing that really gives you away as a troll. Never, ever admit you're not interested in the subject matter, or the whole gig is up.
>>>>>>>
Let's see, do YOU care about the protocol your email system uses? TCP pisses me off, but POP3 could be made by MS and still not bug me.
X11 has been around for how many years? Meanwhile, this is the third or fourth major iteration of the Macintosh graphics interface? Riiight.
>>>>>>
How often has X crashed on you? It IS possible to design a stable system the first time around, especially if it is a clean design. Still its a moot point. Aqua isn't out yet, so you can't comment on the stability.
However, it is a lot faster and more powerful.
I don't really expect Aqua to be much faster then X11. Perhaps slightly so, simply because it is more limited. But not significantly so.
As far as power goes, you're dead wrong. Extensibility, network transparency, host, machine, and transport independence are just a few of the things X11 has that Mac OS X's graphics system doesn't.
>>>>
Fast? I'd like to see X do those transparency tricks with any modicum of speed. As for power, it depends on your definition. In my eyes, the DPDF and imaging features make for a much more powerful system than simply network transparency. You think anyone uses OpenGL JUST because of the network transparency?
I don't own an IBM mainframe or a Palm Pilot.
No shit? Like that makes a whole hell of a lot of difference to my argument. The point was, X11 will go with you no matter where you go, not that you could run it on the IBM S/390 you have in your bedroom.
>>>>
I was kidding. I understand your point, but in truth. How many Mac users interact with anything other than Windows PCs? The question is one of the relevance of features. If Aqua had network transparency, it would just go unused. These days, the vast majority of Mac users are home users and graphics artists. The former rarely have *NIX machines, and the latter usually have powerful client machines, rather than a large back-end server.
And even if they did, the PP doesn't have an X server.
I've seen one for it, so you're wrong yet again.
>>>>>
You're kidding right? My only question is, what the hell? I mean I can understand one for a WinCE HPC, but for the palm pilot?
Actually, the OP and you are both talking out of your ass, because Aqua is really the UI layer, not the graphics layer like X11 is. It's comparing apples to oranges. The point I was trying to make was that standards are a good thing, which you've missed entirely. Instead, and as usual, you've tried to divert the discussion to a flamewar of Unix vs this mythical "desktop OS" you always bring up.
>>>>>>>>
Personal vandetta maybe? My point is that your argueing symantics. What does Aqua mean? Technically yes, it means just the UI layer of MacOSX. In practice, it means the whole enchillada, DPDF and all. This is a comparison between the entire MacOSX display system and X11. And that is a very valid comparison. And where, praytell, did I bring in a mythical "desktop OS?" (BTW> Did you get the apples vs. oranges pun?)
But, let's indulge you. X11 vs Win9X GDI. At least you got the layers right for that one. The GDI is encumbered with backwards compatability with years worth of things that don't exist anymore. It's tied to Windows. It's tied to the Intel platform. The API changes with each major release of the OS. It's poorly and often incorrectly documented. It's propriatary. It's a pain in the ass to work with. It's limited to a single user on a single machine. In short, it's crap
>>>>>>>
Let's indulge you. X11. It's limited by years worth of backwards compatibility. It's limited by things that almost don't exist anymore (like low power clients), it's hard to program for, the API changes with every major release of X
better font handling for one. It's noticably faster (why shouldn't it be, it's in the bloody kernel!) It has and API that is just slightly more complex than X's but has more imaging features. This is the stuff that matters in desktop space. Imaging features and speed. GDI just one-ups X in this respect.
I do know BeOS, but it had nothing to do with this post. BeOS uses neither X nor GDI. However, I've programmed GDI for awhile now, and it surprises me to see that people who promote X, just don't get the fact that the features that make it so great on *NIX (maturity, extensibility, network transparency, flexibility) just don't matter in consumer-space.
Me? no, but other people have, but they're too new to matter. (IPX comes to mind.)
Okay, we've already got Mach OSSed. We've got FreeBSD OSSed. Now all we need is some one to make a good Aqua clone (DPDF and all that good stuff, not a theme) and I can ditch this blasted Linux box.
Is't than kind of recursive, X is harder to port because MacOS X lacks X?