Thanks for the link, you just made my week! This sounds perfect. Plays MP3/MP4/AAC/OGG/WMA, plus all the cool video formats! Any idea how much this will cost?
Haven't you got that backwards? All else being equal, a faster RAMDAC will mean a sharper picture. The higher the frequencies, the closer you can simulate sharp corners. The same way (but going the other way) that sampling at low freqeuncies gives a poor waveform.
Ahh, I finally realized how you're thinking... unfortunately, it's wrong.;) A RAMDAC is a digital to analog converter, therefore it does NOT sample the way you're thinking of it. It will take each pixel, convert the rgb digital values to an analog voltage and drive the signals out the VGA cable. As the refresh rate increases, these voltages representing individual pixels have to change quicker, increasing the frequency. A faster RAMDAC can therefore drive a higher frequency signal over the cable. However, the freqency of the signal to the monitor is only dependent on resolution and refresh rate, not the maximum speed of the RAMDAC. A higher speed RAMDAC will let you increase the resolution and refresh rate, not (necessarily) increase quality of lower bandwidth modes.
Haven't you got that backwards? All else being equal, a faster RAMDAC will mean a sharper picture. The higher the frequencies, the closer you can simulate sharp corners. The same way (but going the other way) that sampling at low freqeuncies gives a poor waveform.
No, I don't. As you increase the refresh rate, more data needs to be sent over the cable, increasing the frequency of the signals sent over the cable. As the frequency increases, the signal is more susceptable to noise, decreasing the fidelity of the signal. Sampling doesn't really have anything to do with it (its analog data, not digital).
Newer video cards have upped the RAMDAC speed to around 350MHz. That Matrox card probably only supports 200MHz or so. So the question is: what whas the refresh rate at 1280x1024? Decreasing the refresh rate often increases the sharpness. Also, as noted elsewhere, a lot of the GeForce line is pretty bad for 2D quality.
Not sure about VB, but you can download a free C# compiler from microsoft as part of their.NET Framework SDK. You don't get visual studio (you'll probably need to download gvim/winemacs/some_other_code_editor as well). Instead you need to write everything by hand (which isn't quite as bad as you think, even for GUI apps) and compile with the command line (or make if you have cygwin). All in all, probably a better learning environment than QBasic, which was in turn better than TRS-80/C64/AppleII basic that I learned on (stupid crappy tape drives).
Looks like he use icc version 6 to compile. This version of the Intel compiler had it's own libc that it linked to dynamically by default. Version 7 fixed that (switched to glibc, uses statically linked c++ libs). If you can find an install of the version 6 compiler it should work.
It get's uncompressed and burned to a real live audio cd, which you can then re-rip if you want. However, since you're starting with 128K audio, expanding it and then re-ripping it, you won't get the best quality. That's probably the reason they (or Apple) offer anything higher than 128K downloads (along with bandwidth costs).
I often wonder why SGI hasn't tried to do the console thing again. They were the real brains behind the Ultra64 arcade game (and later, Nintendo 64) architecture.
Well, the people who did Ultra64 and Nintendo64 left SGI and formed ArtX, which was bought by ATI. That team went on to design the R300 (Radeon 9700). Most of the rest of SGI's graphics engineers left for Nvidia. SGI doesn't have the graphics expertise they used to...
It looks as though you were using the unmanaged (a.k.a. native) version of DirectX when doing the C++ port. You could use managed C++ and use the managed DX bindings. If you had done that, the DX interfaces would be EXACTLY the same between (managed) C++ and C#. This is because you would be using the exact same interfaces. The managed interfaces to DX are greatly simplified and a little less flexible than the native C/C++ interfaces.
FYI, the DirectDraw interface in managed DX is just a wrapper around making D3D calls. There is no DirectDraw layer ANYWHERE in DX9. The managed interface just makes it easier to do 2D operations, everything ends up going through the 3D driver eventually.
Finally, I agree, the managed DX documentation is no where near as complete as the native DX docs.
Hyperthreading was built into the very first Pentium 4 (Willamette) processor, who's design started around 1994 (maybe 1995, I don't remember) under the codename P68. Regardless of when the design started, the first chip was released in what, 2000? That's well before Intel hired most of the Alpha team and got IP rights to Alpha technology.
Now, I'm not saying the Intel invented SMT (hyperthreading), but they didn't really just take it from Compaq either.
Most of the Intel inventions are either not disclosed (trade secret), or are modifications of existing technology to make it commercially feasible. Much of the process technology Intel adopts (or not adopts) is due to cost considerations, not just processor performance. Therefore, while IBM probably has technically better process technology, Intel has better yeilds (lower cost per processor).
Some "inventions" created by Intel include:
- the first microprocessor (4004) - the first commercially used 2-level adaptive branch prediction (Pentium Pro) (invented with research done by Prof Yale Patt and his students)
- USB - PCI - AGP - PCI Express (most of these buses were done by working groups headed by Intel)
- the first commercially used post-decode trace cache (Pentium 4) - lot's of low power techniques with Pentium M
The Pentium-M (a.k.a. Banias, Centrino) is an updated P3 core with larger caches and support for the P4 instruction set (SSE2, etc.). It's been nearly designed from scratch to be low power. So yes, it *IS* low power, it *IS* fast, it *DOES* run cooler. It's not as fast as a P4M 2.4 proc, but when you're waiting for the slow as hell hard drive and memory, does it matter? I personally can't wait for these to come (and later drop in price;)
I was introduced to WOT in the summer of '01 by a friend who happened to have the first 9 books. I ended up reading all of them in about 2 months; I just couldn't put them down! So, it was with great anticipation that I received Crossroads of Twilight. I finally get to find out what happens with about 3 plot lines that have been leading up to something great. Then, I read the book.
Damn Jordan to Hell! I read the book and... NOTHING HAPPENS!!! He spends 700 pages going over a month or so time frame from 3-4 different plot lines and creeping them all just a little bit closer to where something will actually occur. I'm tempted to just forget this series. I've read that he plans 3 more books, but if they're exciting as Crossroads, I think I'll just pass.
You still have to get the license file and install it where necessary, but try an `emerge icc`. It does work (by doing pretty much exactly what you did by hand...). What I really want is the ability to put USE='icc' in make.conf.
Ease of use. With Direct3D, you have to set up all of that Win32 specific crap. Its a pain in the ass. You have to memorize all of those silly structure names and such (don't quiz me as I don't know any of them). With OpenGL, in VC++, you just have to include the right libraries (opengl32.lib, glu32.lib and glut32.lib) and your set to go. I'm pretty sure its similar on Linux.
Right... Either you've never used DX8/9, you've never used OpenGL without glut, or both. Both API's have their good points and bad points in ease-of-use. But as of today (and especially with DX9), I would give the nod to D3D here. There are too many things that are vendor specific in OpenGL that are required for fast operation. This turns into a big pain in the ass. Also, anyone who's written wrapper code to dynamically load DX or OpenGL libraries at run time knows that the C++ interface of DX is a godsend.
Cross platform. Direct3D doesn't run on other platforms (yeah, there's probably a project or two on sourceforge to prove me otherwise), but in general, you don't have to install any fancy things to get OpenGL working on multiple computers. In fact, if you use the GLUT (although deprecated, it has its uses) library, then theorhetically, you should only have to recompile the application to have it run on a specific platform.
Cross platform is right, easy to port, not-so-right. Even when using glut, extensions that exist on the PC's are usually different than apple's extionsions that do the same damn thing. Apple's policy towards OpenGL is similar to the way MS treats DX. The only time the API is updated is when Apple approves of new GL_APPLE extensions. There is no aglGetProcAddress, so vendors are not at liberty to add new extensions when they please. I'll admit that this could be viewed as a good thing, but it does make developing at the bleeding edge more than a little difficult.
John Carmack. Face it, the mans incredible. He's literally changed the face of graphics, but I'm sure everyone already knew that;).
Unfortunately, only John Carmack can tell the IHV's what to do and what extensions to support in OpenGL. Yes, he's helped OpenGL, but what does Carmack have to do with you choosing to use OpenGL vs. DX?
The general API is nicer looking. To me, and I'm sure a lot of other people, code aesthetics is very important. OpenGL uses simple, yet intuitive function names. I want my object to be 100% red, and 50% blue, and 0% green, simple, I must use the glColor3f(1.0f, 0.5f, 0.0f); function (gl - the library, Color - main identifier, 3f - takes 3 floats as arguments). I'm not sure of the function in Direct3D, but I'm sure its not as nice looking.
Write back when you've tried using programmable shaders under OpenGL (especially fragment/pixel shaders). Personally (and I know I don't speak for everyone), I perfer the DX api to GL's. I also prefer DX's standard vertex lighting model to GL's (the spot light formulae (sp?) are different). The DX fixed function pixel pipeline is more flexible than GL's standard (GL_ARB_texture_env_combine) pixel pipeline.
In my summary:
OpenGL and DX are very equivalent in functionality. OpenGL tends to have MORE function calls into the library, but DX has more EXPENSIVE function calls into the library - so this is a wash. I do hope OpenGL 2.0 will kick ass, but I'm also hoping it's a step towards the day when DX and OpenGL have easily translatable shading languages and features for everything. It's not there yet.
You should read the install instructions on the Gentoo site. If you have a bootable floppy that can:
- fdisk the install drive / partitions - format the partitions - give you a working network connection - Let you run a command shell with ftp and chroot working
That's all you need. You can probably use that Debian floppy to install Gentoo. Of course, there's the matter of downloading a 50-100 MB tarball + kernel sources for the initial install, plus more downloading and several hours of compiling to get a usable system. But you can do it without a CD (or even a CD-ROM drive).
To be honest, I don't know how much influence marketing influenced the design, but I would guess that it was a small, ableit tangable, presence.
If you look at Athlon vs. P4, they have different design goals, yet result in similar performance. Looking at ItaniumII, I would guess that Intel is just as able to go the high IPC route as AMD, but chose the clockspeed route for the desktop. So, that may have been a marketing push, and looking at sales figures, it paid off. However, even the original P4 was designed for hyperthreading, a technology designed purely to get more work done per clock on applications that are most used by servers and power users. Intel has also stated publicly (a news.com story?) that they are looking to multi-core designs to increase performance. Even they recognize that ramping up clockspeed has diminishing returns.
I don't know anything about the 487, although I would imagine they built it because their customers asked for it (seems like something an OEM would love). As for the FDIV bug, I found out a little about that when I interned for an Intel customer support group in '97. That $500 million fiasco totally transformed their entire customer support infrastructure. Intel now publishes erratta on all known and confirmed deviations from spec for every processor they sell (something that AMD might want to consider if they hope to get Opteron adopted in the server room). I can say with confidence that something like that will NOT happen again (well, maybe the bug would, but the response would be much better next time).
BTW, I didn't have to prove I had the flaw/bug/whatever. I just called up, told them I had a P90, they sent me a new one (that would overclock to a P100 - woohoo!). This was before the internship...
Re:Another reason to forget about megahertz
on
Pentium 4 2.8GHz
·
· Score: 3, Insightful
Why does everyone think that the processor with the most work done per clock is automatically better? Sure the PIII has a higher IPC than the P4 does, it was by design!
The P4 was designed to get the most performance out of whatever process it was fab'ed on. If you look at the results, by and large they succeeded. Sure the PIII is more efficient, but at 180 nm, they could only be clocked reliably up to about 1.1 GHz. The P4 hit 2 GHz. On 130 nm, the PIII tops out at ~1.4 GHz, the P4 is up to 2.8 Ghz, and will probably top out at 3 - 3.4 GHz. So, is a P3 running at 1.5GHz "better" than a P4 running at 3 GHz because it does more work per clock? Your argument assumes that you could run a P3 at the same clock speed as a P4 - it can't.
The funny thing is, Intel also makes one of the highest IPC (and highest performing) processors currently available, the Itanium II. For floating point code, it has the highest IPC of any processor currently avaialble. At 1 GHz it's floating point performance is just a smidge under IBM's Power4 running at 1.3 GHz. It's integer performance isn't too much under the latest P4/AthlonXP procs - and it's only running at 1 GHz!!! Does anyone on/. laud Intel for making such an efficient processor? No, they bitch and moan about how the P4 is so "inefficient" and how uber cool AMD is for releasing fast processors really cheaply.
Here's a thought, maybe they sell Athlons really cheaply because the HAVE to, not because WANT to. Companies don't lose money because they're trying to be nice to their customers. The best price/performance option in *any* industry is almost never with the market leader, because the people trying to catch up will trade profits for market share. So, I guess in the end, yay for competition (just try not to be so biased, open your mind).
Oops, my bad. I guess technically it was a VSA-100 processor. The VSA-100 was then used in the V4 and V5 video cards.
GPU - graphics processing unit. The VSA-100 processed graphics (triangles). It just didn't do transform and lighting (or vertex/pixel shaders). Just because it isn't as full featured as a GF4 doesn't mean you can't use the generic GPU term for them. That's like saying that the 386 isn't a CPU because it doesn't have a floating point unit. (Yes, I know that Nvidia coined the term with the intro of the GeForce 256, but I still stand by what I said...)
The 5500 had a HD power connector on it for an internal direct plugin to the power supply. The 6000 has a cord that goes out of the computer, through a power converter brick, and into a wall socket.
I saw the inq's report as well. I don't really have a problem with this approach, but a separate plug into the wall is a bit much...
Do you even know what a V5 6000 is? It's a 4 GPU version of the V3!!!
Think about it. This card is 2-3 years old. The architecture is what matters. Not the amount of GPUs.
Again, this card had 4 processors!
...The GeForce4 4600 can't even consider 8xAA. The V5 6K does, and it does it well. On 128M of SDRAM.
It sort of had 128M of RAM. It actually has 32MB of RAM per processor. So, all the latest games that use up more than 32MB of RAM in texture / geometry caching will run really slowly on the V5. Also, for those that don't remember, this was the card that you had to plug into the wall separately from the computer.
Don't get me wrong, I've used the V5 5500 (2 GPU version), and it was really cool at the time. But I'll take a GF4 any day of the week over any voodoo you offer me (unless of course I can sell it at the collector's item price:)
Personally, I think Cg (or a derivitive) will eventually be used for movies. Eventually these kind of tools (and hardware) will reach a point where they can compute the same algorithms that renderman, etc. use internally (to something very close to the same precision). This then can be executed on a graphics card at much greater speed than can be done on a traditional CPU.
However, this doesn't imply that the rendering by the graphics card will be real-time. Renderings per frame may drop to minutes instead of hours, but it probably won't be interactive. Also, the same amount of work by artists tweaking animation and doing post production still applies. Basically, graphics hardware will replace 1 portion of the pipeline, not the entire thing. It will probably be many years before hardware can generate really convincing photorealistic images at interactive rates (don't listen to the marketer speak of graphics IHV's!)
Post-production will always exist, it's not like it was invented with CGI. They use post-production techniques on live-action film sequences as well, why would it be any different if the CGI was generated in real-time (like camera photography already is).
Re:more taxpayer money down the toilet
on
Stellar Water Fountain
·
· Score: 2, Interesting
Aside from not (to my knowledge) being a publicly funded project (at least by the U.S.), I don't agree with the point you're trying to make.
In the grand scheme of things, how much do "space fountains" really matter?
...
I don't want to have to explain to my grandkids that the reason I'm dying of brain disease in the year 2075 is because we were too busy looking for space waterslides to find a cure.
While it may be more important to you to find a way to live longer instead of researching the nature of the universe, I really doubt it would benefit humanity as much. Given current population density growth, it would be much better for everyone if the average life expectancy started going down, not up. The way things are going, it won't be long until there are more people too senile to go to the bathroom by themselves than there will be active, useful members of society. They only reason they won't be allowed to die is because thier kids can't stand the thought of them not being around for the grandkids to see on Christmas. Call me a cruel heartless bastard, but I think scientific research into the mysteries of the universe is monumentally more important to humanity than the difference between our grandparents living to be 70 or our grandparents living to be 100.
Windows XP contains theme support. You can get themes here. However, to actually use themes not signed by microsoft, you need an additional shareware program that costs $20 for long-term activation (this program is not written by MS). Seems to work pretty well, although the themes don't apply equally to all apps.
On the contrary, I would love it if Gentoo or Slackware were designed to use icc instead of gcc. Aside from the performance gain of the compiled code (which, as you said may be negligible in most situations), the actual time it takes to compile is much, MUCH shorter with icc than with gcc. Especially with C++ code (KDE/QT anyone?).
I do love having gcc available everywhere, but I also wish they would spend some time optimizing actual compile time (maybe only when code output optimizations are tunred off?). Having a compile time for very large projects be 30 *minutes* shorter with icc is a real productivity boost.
Slashdot Mirror
Thanks for the link, you just made my week! This sounds perfect. Plays MP3/MP4/AAC/OGG/WMA, plus all the cool video formats! Any idea how much this will cost?
Ahh, I finally realized how you're thinking ... unfortunately, it's wrong. ;) A RAMDAC is a digital to analog converter, therefore it does NOT sample the way you're thinking of it. It will take each pixel, convert the rgb digital values to an analog voltage and drive the signals out the VGA cable. As the refresh rate increases, these voltages representing individual pixels have to change quicker, increasing the frequency. A faster RAMDAC can therefore drive a higher frequency signal over the cable. However, the freqency of the signal to the monitor is only dependent on resolution and refresh rate, not the maximum speed of the RAMDAC. A higher speed RAMDAC will let you increase the resolution and refresh rate, not (necessarily) increase quality of lower bandwidth modes.
No, I don't. As you increase the refresh rate, more data needs to be sent over the cable, increasing the frequency of the signals sent over the cable. As the frequency increases, the signal is more susceptable to noise, decreasing the fidelity of the signal. Sampling doesn't really have anything to do with it (its analog data, not digital).
Newer video cards have upped the RAMDAC speed to around 350MHz. That Matrox card probably only supports 200MHz or so. So the question is: what whas the refresh rate at 1280x1024? Decreasing the refresh rate often increases the sharpness. Also, as noted elsewhere, a lot of the GeForce line is pretty bad for 2D quality.
Not sure about VB, but you can download a free C# compiler from microsoft as part of their .NET Framework SDK. You don't get visual studio (you'll probably need to download gvim/winemacs/some_other_code_editor as well). Instead you need to write everything by hand (which isn't quite as bad as you think, even for GUI apps) and compile with the command line (or make if you have cygwin). All in all, probably a better learning environment than QBasic, which was in turn better than TRS-80/C64/AppleII basic that I learned on (stupid crappy tape drives).
Looks like he use icc version 6 to compile. This version of the Intel compiler had it's own libc that it linked to dynamically by default. Version 7 fixed that (switched to glibc, uses statically linked c++ libs). If you can find an install of the version 6 compiler it should work.
It get's uncompressed and burned to a real live audio cd, which you can then re-rip if you want. However, since you're starting with 128K audio, expanding it and then re-ripping it, you won't get the best quality. That's probably the reason they (or Apple) offer anything higher than 128K downloads (along with bandwidth costs).
Well, the people who did Ultra64 and Nintendo64 left SGI and formed ArtX, which was bought by ATI. That team went on to design the R300 (Radeon 9700). Most of the rest of SGI's graphics engineers left for Nvidia. SGI doesn't have the graphics expertise they used to...
It looks as though you were using the unmanaged (a.k.a. native) version of DirectX when doing the C++ port. You could use managed C++ and use the managed DX bindings. If you had done that, the DX interfaces would be EXACTLY the same between (managed) C++ and C#. This is because you would be using the exact same interfaces. The managed interfaces to DX are greatly simplified and a little less flexible than the native C/C++ interfaces.
FYI, the DirectDraw interface in managed DX is just a wrapper around making D3D calls. There is no DirectDraw layer ANYWHERE in DX9. The managed interface just makes it easier to do 2D operations, everything ends up going through the 3D driver eventually.
Finally, I agree, the managed DX documentation is no where near as complete as the native DX docs.
Hyperthreading was built into the very first Pentium 4 (Willamette) processor, who's design started around 1994 (maybe 1995, I don't remember) under the codename P68. Regardless of when the design started, the first chip was released in what, 2000? That's well before Intel hired most of the Alpha team and got IP rights to Alpha technology.
Now, I'm not saying the Intel invented SMT (hyperthreading), but they didn't really just take it from Compaq either.
Most of the Intel inventions are either not disclosed (trade secret), or are modifications of existing technology to make it commercially feasible. Much of the process technology Intel adopts (or not adopts) is due to cost considerations, not just processor performance. Therefore, while IBM probably has technically better process technology, Intel has better yeilds (lower cost per processor).
Some "inventions" created by Intel include:
- the first microprocessor (4004)
- the first commercially used 2-level adaptive branch prediction (Pentium Pro) (invented with research done by Prof Yale Patt and his students)
- USB
- PCI
- AGP
- PCI Express (most of these buses were done by working groups headed by Intel)
- the first commercially used post-decode trace cache (Pentium 4)
- lot's of low power techniques with Pentium M
There are a lot more, but usually not public.
The Pentium-M (a.k.a. Banias, Centrino) is an updated P3 core with larger caches and support for the P4 instruction set (SSE2, etc.). It's been nearly designed from scratch to be low power. So yes, it *IS* low power, it *IS* fast, it *DOES* run cooler. It's not as fast as a P4M 2.4 proc, but when you're waiting for the slow as hell hard drive and memory, does it matter? I personally can't wait for these to come (and later drop in price ;)
I was introduced to WOT in the summer of '01 by a friend who happened to have the first 9 books. I ended up reading all of them in about 2 months; I just couldn't put them down! So, it was with great anticipation that I received Crossroads of Twilight. I finally get to find out what happens with about 3 plot lines that have been leading up to something great. Then, I read the book.
... NOTHING HAPPENS!!! He spends 700 pages going over a month or so time frame from 3-4 different plot lines and creeping them all just a little bit closer to where something will actually occur. I'm tempted to just forget this series. I've read that he plans 3 more books, but if they're exciting as Crossroads, I think I'll just pass.
Damn Jordan to Hell! I read the book and
You still have to get the license file and install it where necessary, but try an `emerge icc`. It does work (by doing pretty much exactly what you did by hand...). What I really want is the ability to put USE='icc' in make.conf.
Right... Either you've never used DX8/9, you've never used OpenGL without glut, or both. Both API's have their good points and bad points in ease-of-use. But as of today (and especially with DX9), I would give the nod to D3D here. There are too many things that are vendor specific in OpenGL that are required for fast operation. This turns into a big pain in the ass. Also, anyone who's written wrapper code to dynamically load DX or OpenGL libraries at run time knows that the C++ interface of DX is a godsend.
Cross platform. Direct3D doesn't run on other platforms (yeah, there's probably a project or two on sourceforge to prove me otherwise), but in general, you don't have to install any fancy things to get OpenGL working on multiple computers. In fact, if you use the GLUT (although deprecated, it has its uses) library, then theorhetically, you should only have to recompile the application to have it run on a specific platform.
Cross platform is right, easy to port, not-so-right. Even when using glut, extensions that exist on the PC's are usually different than apple's extionsions that do the same damn thing. Apple's policy towards OpenGL is similar to the way MS treats DX. The only time the API is updated is when Apple approves of new GL_APPLE extensions. There is no aglGetProcAddress, so vendors are not at liberty to add new extensions when they please. I'll admit that this could be viewed as a good thing, but it does make developing at the bleeding edge more than a little difficult.
John Carmack. Face it, the mans incredible. He's literally changed the face of graphics, but I'm sure everyone already knew that ;).
Unfortunately, only John Carmack can tell the IHV's what to do and what extensions to support in OpenGL. Yes, he's helped OpenGL, but what does Carmack have to do with you choosing to use OpenGL vs. DX?
The general API is nicer looking. To me, and I'm sure a lot of other people, code aesthetics is very important. OpenGL uses simple, yet intuitive function names. I want my object to be 100% red, and 50% blue, and 0% green, simple, I must use the glColor3f(1.0f, 0.5f, 0.0f); function (gl - the library, Color - main identifier, 3f - takes 3 floats as arguments). I'm not sure of the function in Direct3D, but I'm sure its not as nice looking.
Write back when you've tried using programmable shaders under OpenGL (especially fragment/pixel shaders). Personally (and I know I don't speak for everyone), I perfer the DX api to GL's. I also prefer DX's standard vertex lighting model to GL's (the spot light formulae (sp?) are different). The DX fixed function pixel pipeline is more flexible than GL's standard (GL_ARB_texture_env_combine) pixel pipeline.
In my summary: OpenGL and DX are very equivalent in functionality. OpenGL tends to have MORE function calls into the library, but DX has more EXPENSIVE function calls into the library - so this is a wash. I do hope OpenGL 2.0 will kick ass, but I'm also hoping it's a step towards the day when DX and OpenGL have easily translatable shading languages and features for everything. It's not there yet.
You should read the install instructions on the Gentoo site. If you have a bootable floppy that can:
- fdisk the install drive / partitions
- format the partitions
- give you a working network connection
- Let you run a command shell with ftp and chroot working
That's all you need. You can probably use that Debian floppy to install Gentoo. Of course, there's the matter of downloading a 50-100 MB tarball + kernel sources for the initial install, plus more downloading and several hours of compiling to get a usable system. But you can do it without a CD (or even a CD-ROM drive).
If you look at Athlon vs. P4, they have different design goals, yet result in similar performance. Looking at ItaniumII, I would guess that Intel is just as able to go the high IPC route as AMD, but chose the clockspeed route for the desktop. So, that may have been a marketing push, and looking at sales figures, it paid off. However, even the original P4 was designed for hyperthreading, a technology designed purely to get more work done per clock on applications that are most used by servers and power users. Intel has also stated publicly (a news.com story?) that they are looking to multi-core designs to increase performance. Even they recognize that ramping up clockspeed has diminishing returns.
I don't know anything about the 487, although I would imagine they built it because their customers asked for it (seems like something an OEM would love). As for the FDIV bug, I found out a little about that when I interned for an Intel customer support group in '97. That $500 million fiasco totally transformed their entire customer support infrastructure. Intel now publishes erratta on all known and confirmed deviations from spec for every processor they sell (something that AMD might want to consider if they hope to get Opteron adopted in the server room). I can say with confidence that something like that will NOT happen again (well, maybe the bug would, but the response would be much better next time).
BTW, I didn't have to prove I had the flaw/bug/whatever. I just called up, told them I had a P90, they sent me a new one (that would overclock to a P100 - woohoo!). This was before the internship...
The P4 was designed to get the most performance out of whatever process it was fab'ed on. If you look at the results, by and large they succeeded. Sure the PIII is more efficient, but at 180 nm, they could only be clocked reliably up to about 1.1 GHz. The P4 hit 2 GHz. On 130 nm, the PIII tops out at ~1.4 GHz, the P4 is up to 2.8 Ghz, and will probably top out at 3 - 3.4 GHz. So, is a P3 running at 1.5GHz "better" than a P4 running at 3 GHz because it does more work per clock? Your argument assumes that you could run a P3 at the same clock speed as a P4 - it can't.
The funny thing is, Intel also makes one of the highest IPC (and highest performing) processors currently available, the Itanium II. For floating point code, it has the highest IPC of any processor currently avaialble. At 1 GHz it's floating point performance is just a smidge under IBM's Power4 running at 1.3 GHz. It's integer performance isn't too much under the latest P4/AthlonXP procs - and it's only running at 1 GHz!!! Does anyone on /. laud Intel for making such an efficient processor? No, they bitch and moan about how the P4 is so "inefficient" and how uber cool AMD is for releasing fast processors really cheaply.
Here's a thought, maybe they sell Athlons really cheaply because the HAVE to, not because WANT to. Companies don't lose money because they're trying to be nice to their customers. The best price/performance option in *any* industry is almost never with the market leader, because the people trying to catch up will trade profits for market share. So, I guess in the end, yay for competition (just try not to be so biased, open your mind).
If the inputs are A, B, and C, then is:
(A&B)|(B&C)|(A&C)
the easy way or the hard way? It's only 5 instructions (well 9 if you count loading and storing to memory).
Oops, my bad. I guess technically it was a VSA-100 processor. The VSA-100 was then used in the V4 and V5 video cards.
GPU - graphics processing unit. The VSA-100 processed graphics (triangles). It just didn't do transform and lighting (or vertex/pixel shaders). Just because it isn't as full featured as a GF4 doesn't mean you can't use the generic GPU term for them. That's like saying that the 386 isn't a CPU because it doesn't have a floating point unit. (Yes, I know that Nvidia coined the term with the intro of the GeForce 256, but I still stand by what I said...)
The 5500 had a HD power connector on it for an internal direct plugin to the power supply. The 6000 has a cord that goes out of the computer, through a power converter brick, and into a wall socket.
I saw the inq's report as well. I don't really have a problem with this approach, but a separate plug into the wall is a bit much...
Think about it. This card is 2-3 years old. The architecture is what matters. Not the amount of GPUs.
Again, this card had 4 processors!
It sort of had 128M of RAM. It actually has 32MB of RAM per processor. So, all the latest games that use up more than 32MB of RAM in texture / geometry caching will run really slowly on the V5. Also, for those that don't remember, this was the card that you had to plug into the wall separately from the computer.
Don't get me wrong, I've used the V5 5500 (2 GPU version), and it was really cool at the time. But I'll take a GF4 any day of the week over any voodoo you offer me (unless of course I can sell it at the collector's item price :)
Personally, I think Cg (or a derivitive) will eventually be used for movies. Eventually these kind of tools (and hardware) will reach a point where they can compute the same algorithms that renderman, etc. use internally (to something very close to the same precision). This then can be executed on a graphics card at much greater speed than can be done on a traditional CPU.
However, this doesn't imply that the rendering by the graphics card will be real-time. Renderings per frame may drop to minutes instead of hours, but it probably won't be interactive. Also, the same amount of work by artists tweaking animation and doing post production still applies. Basically, graphics hardware will replace 1 portion of the pipeline, not the entire thing. It will probably be many years before hardware can generate really convincing photorealistic images at interactive rates (don't listen to the marketer speak of graphics IHV's!)
Post-production will always exist, it's not like it was invented with CGI. They use post-production techniques on live-action film sequences as well, why would it be any different if the CGI was generated in real-time (like camera photography already is).
In the grand scheme of things, how much do "space fountains" really matter?
I don't want to have to explain to my grandkids that the reason I'm dying of brain disease in the year 2075 is because we were too busy looking for space waterslides to find a cure.
While it may be more important to you to find a way to live longer instead of researching the nature of the universe, I really doubt it would benefit humanity as much. Given current population density growth, it would be much better for everyone if the average life expectancy started going down, not up. The way things are going, it won't be long until there are more people too senile to go to the bathroom by themselves than there will be active, useful members of society. They only reason they won't be allowed to die is because thier kids can't stand the thought of them not being around for the grandkids to see on Christmas. Call me a cruel heartless bastard, but I think scientific research into the mysteries of the universe is monumentally more important to humanity than the difference between our grandparents living to be 70 or our grandparents living to be 100.
Windows XP contains theme support. You can get themes here. However, to actually use themes not signed by microsoft, you need an additional shareware program that costs $20 for long-term activation (this program is not written by MS). Seems to work pretty well, although the themes don't apply equally to all apps.
On the contrary, I would love it if Gentoo or Slackware were designed to use icc instead of gcc. Aside from the performance gain of the compiled code (which, as you said may be negligible in most situations), the actual time it takes to compile is much, MUCH shorter with icc than with gcc. Especially with C++ code (KDE/QT anyone?).
I do love having gcc available everywhere, but I also wish they would spend some time optimizing actual compile time (maybe only when code output optimizations are tunred off?). Having a compile time for very large projects be 30 *minutes* shorter with icc is a real productivity boost.