A non-pipelined FPU in that day and age still sucked. There are some tests in which a pentium MMX beat a K6 chip on FPU tests. Whether or not the K6 was an effective implementation of a non-pipelined FPU is a moot point. Either way, it performed very poorly compared to a P6 class chip.
You're mostly right except for the fact that the current Athlon is quite SPM capable. It has all the on-chip faccilities required for SPM. It's just that current Athlon chipsets, (The KX-133 and the AMD 750 Irongate) don't support SMP.
People don't seem to realize that the optimizing process is highly processor dependant. A program optimized for the PPro will not take full advantage of the Athlon. A) It can't schedule instructions properly. P6 level chips have one FPU while the Athlon has three. B) The Athlon can juggle many more instructions at a time, so scheduling again can't be optimized properly. C) The internal microarchitecture (yikes!) is very different between the two chips. I doubt the same optimizations would work for both. For example, there are two types of x86 instructions to K7 and P6 level chips, direct path and vector path. (at least that's what the athlon calls them) Instructions which can get translated directly into one macro OP for consumption by the K7 RISC internals are called direct path, and intructions that need more steps and are translated into multiple macro ops are called vector path. Different sets of instructions take the two paths in the two different chips, so the compiler can't correctly optimize the code to include mostly the direct path instructions on the P6 without hurting the performance of the K7.
Well the guy probably had a reason for buying the 400MHz Intel vs. the AMD one, even if the AMD was cheaper. The only Intel/AMD chips available at that speed were the PII/Celerons and the K6s. Most likely, he did not want to buy the K6 and take the massive fpu performance hit that it entailed. (Seriously, Boot once said that the K6 had such bad math skills it must have gone to an inner city high school. Ouch!)
Actually, most games support 3DNow!, and Quake III runs faster on an Athlon than a PIII at the same clock speed. Also, DirectX has support for both 3DNow! and SSE, so it is even there. FPU intensive apps also perform better on Athlon, like you said. The only reason to buy a PIII would be to support SSE-only apps such as Photoshop 5.5, which run much faster on PIII because of the SSE extensions.
Re:Hmm, no flames now that it has Linux support?
on
WinDSL Coming?
·
· Score: 2
Actually, I've seen a grand total of three posts complaining about lack of alternate OS support as of 11:00 AM EST. One vageuly alluded to it, and the other was posted as AC 0 so it was hidden. I do admit that I missed one that was posted at around 8:30 this morning, because it was very far down the list. I can assure you if these modems were windows only, there would be a mad run of flames down this entire post. It is true that most don't care about the Linux drivers, and think this is crappy hardware; I never said otherwise. The first part of my post was just pointing out that this supported Linux, but not other OSs, and they should open the specs to allow other OSs to be supported. Related to that I would like to point out that this is not like closed spec video cards, which I support. There is really no point in keeping the specs to cheap DSL modems closed. I doubt people are going to shop around for which software modem can squeeze the most framerate out of Quake! Thus, giving competitors some insight into how your hardware works doesn't help them, because I doubt there is some incredible engineering pipeline behind this modem like there is with, say a GeForce.
Hmm, no flames now that it has Linux support?
on
WinDSL Coming?
·
· Score: 1
I find it interesting nobody is flaming this WinDSL solution for its blocking out of alternate OS users. Of course on/. an alternate OS is Linux, but to the rest of the world, this is still a closed product incompatible with their systems. Meaning that anybody that uses BeOS or OS/2 or even WindowsNT in some cases will not be able to use this modem. This is even bad for the embedded product market because a lot of them are running customs OSs, or something like QNX or BeIA, and these products won't be able to use this DSL, even though it would be ideal for it. And iOpener, for example, has a 200MHz processor, and is only used for web browsing, so it is easily capable of supporting the extra overhead of software DSL. Another thing that I don't see mentioned is exactly what market this is targeted at. There is no such thing as cheap DSL. In most parts of the country, DSL costs $40-$50 a month, (unless you are lucky enough to live in the midwest where one can get 1.5 mbps DSL for $29.95 a month!) and thus any $50 or even $100 savings on the cost of the modem isn't likely to expand the market much. On top of that you have the fact that most of the more expensive routers and such have large rebates attached (I'm getting a Netopia router for $200 after rebate) so in the end hardware costs really aren't significant in a DSL purchase.
Interesting conundrum. Is it still being rednecky if one imposes ones views about letting people have differing views? In theory one would say yes, but in practice it is shown that usually people who try to force beliefs about open beliefs have better intents.
Yea, but I doubt management features will carry the load of a large web server. I'm saying that if they intend to put this in the normal Xeon market, then they need more cache, or else people are going to continue to use the older proc, or they will get whopped by AMD and its 8meg cache Athlon.
I can't understand why, when anyone comes out to complain about the GPL, the BSD license immediatly comes up as a target. There is nothing wrong with the BSD license. It is a much more open license, and is appropriate for people who want their code to be used as widely as possible and don't care if it gets used in propriotory products. The GPL is great for people who want to share their code, but don't want it used unless that developer too shares their code. Both have different purposes, and different kinds of people use them. I doubt the BSD people care that MS uses a great deal of BSD code in their networking, or that IBM bases propriotory products on BSD. (The JetWeb or WebJet or something?) So in the end, you use whatever license you like. If you aren't a redneck, you don't critisize other people for what license they like.
I doubt it. The BeOS kernel isn't exactly large and it is an entirely different beast than the stuff that uses GPLd code. You have to remember that most GPLd stuff is in the POSIX libraries, (like libroot.so and maybe the C and C++ libraries.) All the other stuff is nothing like POSIX (okay, the Net stuff is for now, but not for long.) and thus a lot of the GPLd libraries would be hard to implement. Does that mean that there's not any GPLd code anywhere else in the system? Probably not, but I doubt it is in the kernel. It is: A) Fairly small. B) Not subject to the numberous linking of different propriotory and LGPLd object files like libroot is. Since libroot has so many different object files, some propriotory, and some LGPL, it is very understandable that something under the GPL would escape detection like that.
Hello, what is this vehemance against the BSD license? I doubt the BSD license people think that nobody is going to rip of them. I think they know that and the point of placing something under the BSD license is to let people use it in propriotory projects. If they wanted to "protect" their code, they'd use the GPL, or (heaven forbid) come up with their own license?!!!!
Actually there are currently 2 ports of Java2 to BeOS. One is coming from Be themselves in close cooperation with Sun, and one is coming from an independant group based on Kaffe called BeKaffe.
Oh come on. The last time was in the bootloader somewhere, and that was back in the DR releases. Both cases were also fairly minor points, in this one it was a confusion between the GPL and the LGPL.
Is it just me, or does Intel's new "use one die" for everything seem to have gotten them into a little trouble? I read the article, look for how exactly the new Xeon is different from a Coppermine PIII. Isn't the whole point of a Xeon the large full speed L2 cache? With the PIII having a 256K full speed cache, isn't a 256K Xeon, well, redundant? I do hope there are 2 meg integrated Xeons coming soon, because otherwise, you pay more for almost exactly the same processor.
I would just like to point out that this was out a week ago on OpenGL.org. What took so long? Aside from that bitch, I think this is a revolutionary API. Some people are saying that this isn't really a DirectX competitor and that you should use SDL or something for games. Wrong. First, DirectX is not just a games API, it is applicable to all media apps. (I think even MS Office uses DirectDraw.) Second, it the state of OpenML is similar to OpenGL. It was originally intended for pro apps, but then people realized that it was great for any 3D app. OpenML will probably be the same way, although the companies behind it now have some hindsight. (Remember, the OGL ARB is on the board.) Third, this IS going to be cross platform DirectX, whether or not its creators intented it to. There is nothing like DirectX on any other platform, and DirectX is a big reason why people don't start developing for alternative OSs. Not just because of the API, but what DirectX means. Direct access to hardware without hardware dependance and without conflicting with other apps. BeOS has some of these APIs in a fairly unified manner, but they aren't as featurefull as DirectX. Linux has nothing remotely close to DirectX. SDL is nice, but is inherently slower since it is layered on top of native APIs. Also, it does not take the world's best advantage of hardware acceleration. Face it, most hardware today are DirectX accelerators. If a large board like the Khronos board can pressure developers to include OpenML acceleration, a fast, powerful cross platform API that can compete with DirectX can emerge. Finally, SDL has nowhere near the features of DirectX. DirectX is addictive. It is the only thing that makes me keep Windows on my harddrive, even though I like programming BeOS much better. It is the only API I've ever seen that can blit 21,000 icon sized sprites in the space of one second. Even OpenGL can't touch it for flexibility. The HAL/HEL is a work of genius, combining the power of hardware acceleration with the niceness of device independance. Lovely. However, it is limited to Windows, which is its one major flaw. Thats why I think OpenML will be so revolutionary. If it can match DirectX, (And I'm sure it will, after all, the OpenGL ARB is onboard) then I can give up windows and game developers can get all the features and power they're used to with DirecX with the freedom to port easily to different platforms. On a larger scale, OpenML will essentially fill in a large gap in POSIX. POSIX has become a very well accepted cross platform API, but is limited in usefullness because of its lack of media/graphics/etc features. This is a major thorn to game developers, because aside from code unique to the application, most of code is graphics or sound API code. By making this API cross platform, we can now see cross platform apps that aren't cut down to the least common denemenator of the OSs that it supports.
Actually it is the same situation as with Linux and Windows and RAM. Flaky RAM tends to bring down Linux much easier than Windows. Also, overclocked CPUs tends to bring down BeOS faster than Windows or Linux.
Someone on/. complaining about consistancy? Strange. On Linux you have TK apps, you have GTK+ apps, you have Qt apps, you have Motif apps, you have Athena apps, bash apps, csh apps, ncurses apps, add nauseum. Not bad necessarily, but I don't think a Linux user (you imply you are because of the Gnome comment) is in any position to critisize ANY other OS about consistancy.
True, but it's not expense, it's simplicity. Do you think that average console user can figure out the difference between an ethernet and firewire port? I mean they could write instruction manuals and step by step diagrams, but in the end, why bother? Firewire works just as well, is integrated, and is one less driver that the OS needs to load.
An ethernet card is not necessary for something that has firewire. You can set up a firewire network that approaches the speed of 100mpbs ethernet. Sony actually already does this in their VAIO line of desktop PCs.
Actually no. The SNES CDROM was being developed by Sony in response the SegaCD. Near the end of the project, Nintendo backed out and went with Philips (that project didn't come to anything either.) Pissed off, Sony added some stuff to the design, came out with the Playstation, and ate Nintendo's lunch. If anything, its is Nintendo that did the screwing, not Sony.
Under your logic MacOSX is still newer than Linux. Linux is still very classical UNIXish. Yes, BSD is older, but the design underlying Mach is newer. The system Linux may be new, but they system MacOS X is newer. They design is based on straight UNIX, while Mach is a newer offshoot. Either way, MacOS X is more modern.
A) Yes it is cheap stable and flexible, but it is certainly not fast, (with something like GNOME and GTK or KDE and Qt) B) I doubt artists care about flexibility. They use a standard set of apps for many years at a time. Even a version upgrade is traumatic for most. C) NT is not unstable, nor expensive. I can get a copy of NT Workstation for $200, (or $50 from training books) plus it stays up for a week at a time. NT may crash in server environments, but on the desktop it usually is well behaved. And it rarely crashed to the point where you don't have time to save your work. Macintosh just got true multitasking with OSX and has innards even more modern than Linux. (MACH and BSD) Especially with Mach and its good threading model, OSX looks like a powerhouse media OS. Then, of course, there is BeOS. Fast, stable, flexible (app scripting rocks all hell), free. For a lot of artistic tasks that can get by with ArtPaint or Easel (addmitadly not cream of crop apps, but they're decent) it rocks. Then there is the near future port of the GIMP and the port of the 3D modeler nendo and Maxon's 3D app. If Be keeps the momentum it has now (500,000 downloads over the course of a few days) it will be in the big leauges pretty soon.
Slashdot Mirror
I also think that Quake supports SSE but I wouldn't bet on it. (Though it should since it is an engine that will be licensed out.)
A non-pipelined FPU in that day and age still sucked. There are some tests in which a pentium MMX beat a K6 chip on FPU tests. Whether or not the K6 was an effective implementation of a non-pipelined FPU is a moot point. Either way, it performed very poorly compared to a P6 class chip.
You're mostly right except for the fact that the current Athlon is quite SPM capable. It has all the on-chip faccilities required for SPM. It's just that current Athlon chipsets, (The KX-133 and the AMD 750 Irongate) don't support SMP.
People don't seem to realize that the optimizing process is highly processor dependant. A program optimized for the PPro will not take full advantage of the Athlon.
A) It can't schedule instructions properly. P6 level chips have one FPU while the Athlon has three.
B) The Athlon can juggle many more instructions at a time, so scheduling again can't be optimized properly.
C) The internal microarchitecture (yikes!) is very different between the two chips. I doubt the same optimizations would work for both. For example, there are two types of x86 instructions to K7 and P6 level chips, direct path and vector path. (at least that's what the athlon calls them) Instructions which can get translated directly into one macro OP for consumption by the K7 RISC internals are called direct path, and intructions that need more steps and are translated into multiple macro ops are called vector path. Different sets of instructions take the two paths in the two different chips, so the compiler can't correctly optimize the code to include mostly the direct path instructions on the P6 without hurting the performance of the K7.
Well the guy probably had a reason for buying the 400MHz Intel vs. the AMD one, even if the AMD was cheaper. The only Intel/AMD chips available at that speed were the PII/Celerons and the K6s. Most likely, he did not want to buy the K6 and take the massive fpu performance hit that it entailed. (Seriously, Boot once said that the K6 had such bad math skills it must have gone to an inner city high school. Ouch!)
Actually, most games support 3DNow!, and Quake III runs faster on an Athlon than a PIII at the same clock speed. Also, DirectX has support for both 3DNow! and SSE, so it is even there. FPU intensive apps also perform better on Athlon, like you said. The only reason to buy a PIII would be to support SSE-only apps such as Photoshop 5.5, which run much faster on PIII because of the SSE extensions.
Actually, I've seen a grand total of three posts complaining about lack of alternate OS support as of 11:00 AM EST. One vageuly alluded to it, and the other was posted as AC 0 so it was hidden. I do admit that I missed one that was posted at around 8:30 this morning, because it was very far down the list. I can assure you if these modems were windows only, there would be a mad run of flames down this entire post. It is true that most don't care about the Linux drivers, and think this is crappy hardware; I never said otherwise. The first part of my post was just pointing out that this supported Linux, but not other OSs, and they should open the specs to allow other OSs to be supported. Related to that I would like to point out that this is not like closed spec video cards, which I support. There is really no point in keeping the specs to cheap DSL modems closed. I doubt people are going to shop around for which software modem can squeeze the most framerate out of Quake! Thus, giving competitors some insight into how your hardware works doesn't help them, because I doubt there is some incredible engineering pipeline behind this modem like there is with, say a GeForce.
I find it interesting nobody is flaming this WinDSL solution for its blocking out of alternate OS users. Of course on /. an alternate OS is Linux, but to the rest of the world, this is still a closed product incompatible with their systems. Meaning that anybody that uses BeOS or OS/2 or even WindowsNT in some cases will not be able to use this modem. This is even bad for the embedded product market because a lot of them are running customs OSs, or something like QNX or BeIA, and these products won't be able to use this DSL, even though it would be ideal for it. And iOpener, for example, has a 200MHz processor, and is only used for web browsing, so it is easily capable of supporting the extra overhead of software DSL. Another thing that I don't see mentioned is exactly what market this is targeted at. There is no such thing as cheap DSL. In most parts of the country, DSL costs $40-$50 a month, (unless you are lucky enough to live in the midwest where one can get 1.5 mbps DSL for $29.95 a month!) and thus any $50 or even $100 savings on the cost of the modem isn't likely to expand the market much. On top of that you have the fact that most of the more expensive routers and such have large rebates attached (I'm getting a Netopia router for $200 after rebate) so in the end hardware costs really aren't significant in a DSL purchase.
Interesting conundrum. Is it still being rednecky if one imposes ones views about letting people have differing views? In theory one would say yes, but in practice it is shown that usually people who try to force beliefs about open beliefs have better intents.
Yea, but I doubt management features will carry the load of a large web server. I'm saying that if they intend to put this in the normal Xeon market, then they need more cache, or else people are going to continue to use the older proc, or they will get whopped by AMD and its 8meg cache Athlon.
I can't understand why, when anyone comes out to complain about the GPL, the BSD license immediatly comes up as a target. There is nothing wrong with the BSD license. It is a much more open license, and is appropriate for people who want their code to be used as widely as possible and don't care if it gets used in propriotory products. The GPL is great for people who want to share their code, but don't want it used unless that developer too shares their code. Both have different purposes, and different kinds of people use them. I doubt the BSD people care that MS uses a great deal of BSD code in their networking, or that IBM bases propriotory products on BSD. (The JetWeb or WebJet or something?) So in the end, you use whatever license you like. If you aren't a redneck, you don't critisize other people for what license they like.
To quote Tom Halfhill, "I'm okay, you're okay."
I doubt it. The BeOS kernel isn't exactly large and it is an entirely different beast than the stuff that uses GPLd code. You have to remember that most GPLd stuff is in the POSIX libraries, (like libroot.so and maybe the C and C++ libraries.) All the other stuff is nothing like POSIX (okay, the Net stuff is for now, but not for long.) and thus a lot of the GPLd libraries would be hard to implement. Does that mean that there's not any GPLd code anywhere else in the system? Probably not, but I doubt it is in the kernel. It is:
A) Fairly small.
B) Not subject to the numberous linking of different propriotory and LGPLd object files like libroot is. Since libroot has so many different object files, some propriotory, and some LGPL, it is very understandable that something under the GPL would escape detection like that.
Hello, what is this vehemance against the BSD license? I doubt the BSD license people think that nobody is going to rip of them. I think they know that and the point of placing something under the BSD license is to let people use it in propriotory projects. If they wanted to "protect" their code, they'd use the GPL, or (heaven forbid) come up with their own license?!!!!
Actually there are currently 2 ports of Java2 to BeOS. One is coming from Be themselves in close cooperation with Sun, and one is coming from an independant group based on Kaffe called BeKaffe.
Oh come on. The last time was in the bootloader somewhere, and that was back in the DR releases. Both cases were also fairly minor points, in this one it was a confusion between the GPL and the LGPL.
Is it just me, or does Intel's new "use one die" for everything seem to have gotten them into a little trouble? I read the article, look for how exactly the new Xeon is different from a Coppermine PIII. Isn't the whole point of a Xeon the large full speed L2 cache? With the PIII having a 256K full speed cache, isn't a 256K Xeon, well, redundant? I do hope there are 2 meg integrated Xeons coming soon, because otherwise, you pay more for almost exactly the same processor.
I would just like to point out that this was out a week ago on OpenGL.org. What took so long? Aside from that bitch, I think this is a revolutionary API. Some people are saying that this isn't really a DirectX competitor and that you should use SDL or something for games. Wrong. First, DirectX is not just a games API, it is applicable to all media apps. (I think even MS Office uses DirectDraw.) Second, it the state of OpenML is similar to OpenGL. It was originally intended for pro apps, but then people realized that it was great for any 3D app. OpenML will probably be the same way, although the companies behind it now have some hindsight. (Remember, the OGL ARB is on the board.) Third, this IS going to be cross platform DirectX, whether or not its creators intented it to. There is nothing like DirectX on any other platform, and DirectX is a big reason why people don't start developing for alternative OSs. Not just because of the API, but what DirectX means. Direct access to hardware without hardware dependance and without conflicting with other apps. BeOS has some of these APIs in a fairly unified manner, but they aren't as featurefull as DirectX. Linux has nothing remotely close to DirectX. SDL is nice, but is inherently slower since it is layered on top of native APIs. Also, it does not take the world's best advantage of hardware acceleration. Face it, most hardware today are DirectX accelerators. If a large board like the Khronos board can pressure developers to include OpenML acceleration, a fast, powerful cross platform API that can compete with DirectX can emerge. Finally, SDL has nowhere near the features of DirectX. DirectX is addictive. It is the only thing that makes me keep Windows on my harddrive, even though I like programming BeOS much better. It is the only API I've ever seen that can blit 21,000 icon sized sprites in the space of one second. Even OpenGL can't touch it for flexibility. The HAL/HEL is a work of genius, combining the power of hardware acceleration with the niceness of device independance. Lovely. However, it is limited to Windows, which is its one major flaw. Thats why I think OpenML will be so revolutionary. If it can match DirectX, (And I'm sure it will, after all, the OpenGL ARB is onboard) then I can give up windows and game developers can get all the features and power they're used to with DirecX with the freedom to port easily to different platforms. On a larger scale, OpenML will essentially fill in a large gap in POSIX. POSIX has become a very well accepted cross platform API, but is limited in usefullness because of its lack of media/graphics/etc features. This is a major thorn to game developers, because aside from code unique to the application, most of code is graphics or sound API code. By making this API cross platform, we can now see cross platform apps that aren't cut down to the least common denemenator of the OSs that it supports.
Actually it is the same situation as with Linux and Windows and RAM. Flaky RAM tends to bring down Linux much easier than Windows. Also, overclocked CPUs tends to bring down BeOS faster than Windows or Linux.
Troll.
Linux users->run NT (or even better, BeOS!)
Someone on /. complaining about consistancy? Strange. On Linux you have TK apps, you have GTK+ apps, you have Qt apps, you have Motif apps, you have Athena apps, bash apps, csh apps, ncurses apps, add nauseum. Not bad necessarily, but I don't think a Linux user (you imply you are because of the Gnome comment) is in any position to critisize ANY other OS about consistancy.
True, but it's not expense, it's simplicity. Do you think that average console user can figure out the difference between an ethernet and firewire port? I mean they could write instruction manuals and step by step diagrams, but in the end, why bother? Firewire works just as well, is integrated, and is one less driver that the OS needs to load.
An ethernet card is not necessary for something that has firewire. You can set up a firewire network that approaches the speed of 100mpbs ethernet. Sony actually already does this in their VAIO line of desktop PCs.
Actually no. The SNES CDROM was being developed by Sony in response the SegaCD. Near the end of the project, Nintendo backed out and went with Philips (that project didn't come to anything either.) Pissed off, Sony added some stuff to the design, came out with the Playstation, and ate Nintendo's lunch. If anything, its is Nintendo that did the screwing, not Sony.
Under your logic MacOSX is still newer than Linux. Linux is still very classical UNIXish. Yes, BSD is older, but the design underlying Mach is newer. The system Linux may be new, but they system MacOS X is newer. They design is based on straight UNIX, while Mach is a newer offshoot. Either way, MacOS X is more modern.
A) Yes it is cheap stable and flexible, but it is certainly not fast, (with something like GNOME and GTK or KDE and Qt)
B) I doubt artists care about flexibility. They use a standard set of apps for many years at a time. Even a version upgrade is traumatic for most.
C) NT is not unstable, nor expensive. I can get a copy of NT Workstation for $200, (or $50 from training books) plus it stays up for a week at a time. NT may crash in server environments, but on the desktop it usually is well behaved. And it rarely crashed to the point where you don't have time to save your work. Macintosh just got true multitasking with OSX and has innards even more modern than Linux. (MACH and BSD) Especially with Mach and its good threading model, OSX looks like a powerhouse media OS. Then, of course, there is BeOS. Fast, stable, flexible (app scripting rocks all hell), free. For a lot of artistic tasks that can get by with ArtPaint or Easel (addmitadly not cream of crop apps, but they're decent) it rocks. Then there is the near future port of the GIMP and the port of the 3D modeler nendo and Maxon's 3D app. If Be keeps the momentum it has now (500,000 downloads over the course of a few days) it will be in the big leauges pretty soon.