C++ is just as efficient as C is just as efficient as ASM for small values of efficient. Seriously, though, some modern compilers can produce code that would put many hand-coders to shame. Besides, no matter what the language, the adds would take more than one clock. I belive the fp unit has a couple of clocks latency for fp adds.
Actually, you just contridicted yourself. The Itanium is a lot less complex in instruction fetch, issue, etc, because it relies on the compiler to do that work. From a cursory look at the Itanium ASM doc, it seems that the assembler (or the programmer) organizes all instructions into bundles and instruction groups that can be executed in parallel. This keeps the Itanium from having to do that on its own. Plus, if you look at the Intel C compiler, you'll notice that it supports something called software pipelining, where independent instructions are set up so they can be executed in parallel. As for SPEC numbers, a $1200 Itanium beats an Alpha in floating point. Who gives a bleep about integer performance, the Itanium's is bearable. But look at that fp!
Aye. Again with the bus-speed Nazis. As long as you have a fat cache and a good amount of bus-speed, there are lots of apps that are still CPU bound. Consider, for example, floating point apps that perform better on an Athlon than on a P4, even though the P4 has 3.2GB/sec of bandwidth. True, bus-speeds are important, but so too are processor speeds.
Anyone want to comment on the validity of his verbiosity? The first paragraph seems okay from a vocabulary point of view, but no way in hell I can figure out if the rest of it is even true, much less if it is correct.
True, the bus does become an issue here. However, since cache fills tend to be large (32-64 bytes) it should be possible to have extremely wide busses (like the dual 256bit busses on Alpha workstations) to compensate for a lower clock speed. Also, 20GHz busses won't come around until processors reach 100GHz or so (which is still a bit away) since 1/5 the processor speed speeds to be a fairly regular bus speed. Of course, as many tricks as you put in there, the inherent problem remains, just gets postponed somewhat.
Bloatware providers (those that keep Intel & AMD in business)
www.microsoft.com
www.kde.org
www.gnome.org
www.xfree86.org
www.trolltech.com
www.gtk.org
www.openoffice.org
You see, it's not just MS that spews bloatware. Its simply that while in the UNIX market, different organizations spew bloatware, while in Windows-land, all bloatware spewing is efficiently consolidated into one company.
Well, you may have plenty of RAM, but the more RAM my web browser uses, the less RAM I can give the 3D Studio. Besides, I just feel unclean when a program uses more RAM than it needs to. And yes, while IE may use more RAM than reported (according to the current conspiracy theory) a fully loaded Linux system uses more RAM (yes I'm reading top carefully!) than Win2K. Win2K is obscenely bloated. Thus, a fully loaded Linux system (X4, KDE2, GNOME-libs, kernel 2.4, ALSA, the works) is obscenely bloated.
You say that something that takes up 35MB is *not* a memory hog? IE (which is quite bloated) eats up only 10MB of memory with one window, and 12MB with 3 (www.opengl.org, www.slashdot.org, and www.microsoft.com)
Umm, well written C++ code (BeOS usespace) can be a lot more sevlte than poorly written C code (X11, GNOME et all)
>>>>
Disclaimer: All I mean by this is that the BeOS userspace is C++ yet takes up less than 10MB, while GNOME does less (it is simply a desktop environment) and takes up a good deal more space. Comments about BeOS's deadness are irrelvant to this post. Sheesh, it's sad that I even have to bother to make this point clear. Apparently "on-topic" doesn't ring a bell with a lot of people.
Umm, what are you running this on? IE starts up in a second or two. Hell, Photoshop starts up in less than 40 seconds (on my PII-300). How can you POSSIBLY be happy with a 40/sec startup time for a web brower?
While ps is technically correct, the standard usage is MB/sec and Mbps. The main reason most people use it this way is because it is quite easy to mistype MBps as Mbps, and intoduces some ambiguity in the number. While the author may know perfectly well what he means, the reader doesn't know the author personally and thus thinks the author could have made a mistake (as they often do.) Secondly, the ATA-133 my mistake. I meant ATA-100.
Unix thinking? Please. Windows has generally been much worse about hardware-hungry.
>>>>>>>>
I never said what was the case in practice. Theoretically, UNIX is much more abstracted than Windows. Stuff like DirectX is a good example. Again, I don't say that DirectX is good or bad (I personally love it) its just a lot closer to hardware than anything in UNIX.
But even if you're just going to make the old programs over again with absolutely no feature improvements, it often makes sense to burn processor time to save developer time and make the software cheaper. That's why you see the rise of languages like Perl, Python, C++, and Java and the near disappearance of significant assembly work.
>>>>>>>>>
First, features do not necessarily cause slower more bloated code. Take QNX Neutrino as an example. Secondly, lessening the work of the developer through abstraction is a decent idea at the application level (although too often the abstraction is overkill and the performance hit is large. Take CORBA for example.) However, this thinking doesn't make a lot of sense at the OS level. The OS is largely the limiting factor in most I/O or CPU limited applications, and abstracting at the OS level creates a least common denominator effect. I don't much mind if my ICQ program is a little hefty (as long as the gain through abstraction offsets the performance hit) but if the OS causes my well-tuned 3D renderer to perform poorly, no amount of abstraction in the OS can justify it. The very reason people still use C for OS kernels is that it is almost as fast as ASM, and provides a decent amount of abstraction. Thinking that more CPU power entitles one to create more administrative overhead in the OS simply keeps the user from taking full advantage of his (often expensive) hardware. In concrete terms, if upgrading my CPU from 300MHz to 1200MHz results in a theoretical halving of rendering times, then I don't want my OS cutting in on that gain.
CPU effciency is only one of many criteria you can optimize for. And since more than 90% of computers spend more than 90% of their time idle, other things (like usability and development cost) are often more important.
>>>>>>>>
If you're CPU is 90% idle, you're wasting the power of the computer. You're also not doing video or audio editing and 3D animation.
Faster computers mean that we can increase the abbstraction layers between the hardware and the application to make it EASIER and FASTER to develop complex applications.
>>>>>>>>>
Yuck. Ugly UNIX thinking at its worst. Faster computers should allow you to do more, not devote more resources to administrative overhead.
That's really not very impressive. You should be able to play full screen video on anything over a pentium 200, accelerated video or no.
Re:alternative to nvidia linux only drivers?
on
XFree 4.1.0 Out
·
· Score: 2
Actually, a nice solution to this is VBE/AF. There is an open implementation of this called FreeBE/AF, and basically what it does is provide a standard binary module that contains clean machine code. In other words, the drivers are completely self contained, and any OS can call the procedures in the driver without worrying about OS dependencies. To bad this idea hasn't caught on.
Re:Games: XFree86 with DRI, or Linux FBDev?
on
XFree 4.1.0 Out
·
· Score: 2
For all practical purposes, they do. They have to be open source in order to avoid the driver API of the day syndrome Linux has (or the company distributing them has to maintain dozens of different versions, like NVIDIA). In addition, the kernel developers are outwardly hostile to developers of closed source drivers (as evidenced by a recent kernel traffic thread) and the legal implications of closed source drivers linking to a GPL kernel are sketchy at best.
transparency, documentation and portability...
>>>>>>>>>
99% of the world doesn't consider network transparency a "basic feature." 99% of the world doesn't consider portability a feature. Windows GDI is more well-documented than X11.
X11 lacks such basic features as totally integrated anti-aliasing (extensions, in general, suck). X11 lacks a standard toolkit. X11 lacks high performance, low memory use, and low latency. Most people consider these to be far more important feature than the server or scientifically oriented "features" you specify.
Does that have DRI? Does that have all the extensions? Is that fully competitive with Windows2K in terms of features in addition to having network transparency? If so, why the hell is the X distribution 20MB of code?
Re:Games: XFree86 with DRI, or Linux FBDev?
on
XFree 4.1.0 Out
·
· Score: 2
Umm, does that mean X can't switch resolutions even when running a full-screen game or something? Meaning if I want to play Quake III at 800x600, I have to restart in that mode before starting the program?
Yea, and a lot of drivers require recompiling the kernel. Few drivers are distributed in binary form, and even when they are, they are usually specific to a particular (usually several months old) kernel version.
What the hell? I like BeOS! Is that a crime? Does that mean I'm a rabid Mac user out to destroy everything else? Hell, I even mention that Win2K is the *real* OS for 3D. How is that promoting BeOS? Or do Linux zealots think that all closed source OSs are interchangable?
PS> Dislaimer: Not all Mac users are rabid. Not all Linux users are zealots. Not all BeOS users are bitter.
I'd be cautious of having an opinion about something like that without hedging a bit. While I can see the point that private industry would be more efficient in implementing space programs, but I'd argue that it would lead to short-sightedness in research. Corporations are notoriously short-sighted (ex. AT&T not recognizing until 1998 that the internet would put long-distance carriers out of business) and space research could go from focusing on projects that have little immediate returns (but long term potential gains) to focusing on projects that can make a quick buck. I'd argue that a blend of both public and private research would be ideal, with a public agency like NASA focusing on long-term research (like studying comets, deep space, etc), and private companies focusing on short-term projects (like a moon base).
Slashdot Mirror
C++ is just as efficient as C is just as efficient as ASM for small values of efficient. Seriously, though, some modern compilers can produce code that would put many hand-coders to shame. Besides, no matter what the language, the adds would take more than one clock. I belive the fp unit has a couple of clocks latency for fp adds.
Actually, you just contridicted yourself. The Itanium is a lot less complex in instruction fetch, issue, etc, because it relies on the compiler to do that work. From a cursory look at the Itanium ASM doc, it seems that the assembler (or the programmer) organizes all instructions into bundles and instruction groups that can be executed in parallel. This keeps the Itanium from having to do that on its own. Plus, if you look at the Intel C compiler, you'll notice that it supports something called software pipelining, where independent instructions are set up so they can be executed in parallel. As for SPEC numbers, a $1200 Itanium beats an Alpha in floating point. Who gives a bleep about integer performance, the Itanium's is bearable. But look at that fp!
Aye. Again with the bus-speed Nazis. As long as you have a fat cache and a good amount of bus-speed, there are lots of apps that are still CPU bound. Consider, for example, floating point apps that perform better on an Athlon than on a P4, even though the P4 has 3.2GB/sec of bandwidth. True, bus-speeds are important, but so too are processor speeds.
Anyone want to comment on the validity of his verbiosity? The first paragraph seems okay from a vocabulary point of view, but no way in hell I can figure out if the rest of it is even true, much less if it is correct.
True, the bus does become an issue here. However, since cache fills tend to be large (32-64 bytes) it should be possible to have extremely wide busses (like the dual 256bit busses on Alpha workstations) to compensate for a lower clock speed. Also, 20GHz busses won't come around until processors reach 100GHz or so (which is still a bit away) since 1/5 the processor speed speeds to be a fairly regular bus speed. Of course, as many tricks as you put in there, the inherent problem remains, just gets postponed somewhat.
Bloatware providers (those that keep Intel & AMD in business)
www.microsoft.com
www.kde.org
www.gnome.org
www.xfree86.org
www.trolltech.com
www.gtk.org
www.openoffice.org
You see, it's not just MS that spews bloatware. Its simply that while in the UNIX market, different organizations spew bloatware, while in Windows-land, all bloatware spewing is efficiently consolidated into one company.
Well, you may have plenty of RAM, but the more RAM my web browser uses, the less RAM I can give the 3D Studio. Besides, I just feel unclean when a program uses more RAM than it needs to. And yes, while IE may use more RAM than reported (according to the current conspiracy theory) a fully loaded Linux system uses more RAM (yes I'm reading top carefully!) than Win2K. Win2K is obscenely bloated. Thus, a fully loaded Linux system (X4, KDE2, GNOME-libs, kernel 2.4, ALSA, the works) is obscenely bloated.
You say that something that takes up 35MB is *not* a memory hog? IE (which is quite bloated) eats up only 10MB of memory with one window, and 12MB with 3 (www.opengl.org, www.slashdot.org, and www.microsoft.com)
Umm, well written C++ code (BeOS usespace) can be a lot more sevlte than poorly written C code (X11, GNOME et all)
>>>>
Disclaimer: All I mean by this is that the BeOS userspace is C++ yet takes up less than 10MB, while GNOME does less (it is simply a desktop environment) and takes up a good deal more space. Comments about BeOS's deadness are irrelvant to this post. Sheesh, it's sad that I even have to bother to make this point clear. Apparently "on-topic" doesn't ring a bell with a lot of people.
Umm, what are you running this on? IE starts up in a second or two. Hell, Photoshop starts up in less than 40 seconds (on my PII-300). How can you POSSIBLY be happy with a 40/sec startup time for a web brower?
While ps is technically correct, the standard usage is MB/sec and Mbps. The main reason most people use it this way is because it is quite easy to mistype MBps as Mbps, and intoduces some ambiguity in the number. While the author may know perfectly well what he means, the reader doesn't know the author personally and thus thinks the author could have made a mistake (as they often do.) Secondly, the ATA-133 my mistake. I meant ATA-100.
It is at that point I see Alpha systems with dual 256bit busses and get a little jealous...
For god's sake, its MB/sec or MB/s, not MBps! (Unless you mean that the nForce's super cool new bus is slower than ATA/133!)
Unix thinking? Please. Windows has generally been much worse about hardware-hungry.
>>>>>>>>
I never said what was the case in practice. Theoretically, UNIX is much more abstracted than Windows. Stuff like DirectX is a good example. Again, I don't say that DirectX is good or bad (I personally love it) its just a lot closer to hardware than anything in UNIX.
But even if you're just going to make the old programs over again with absolutely no feature improvements, it often makes sense to burn processor time to save developer time and make the software cheaper. That's why you see the rise of languages like Perl, Python, C++, and Java and the near disappearance of significant assembly work.
>>>>>>>>>
First, features do not necessarily cause slower more bloated code. Take QNX Neutrino as an example. Secondly, lessening the work of the developer through abstraction is a decent idea at the application level (although too often the abstraction is overkill and the performance hit is large. Take CORBA for example.) However, this thinking doesn't make a lot of sense at the OS level. The OS is largely the limiting factor in most I/O or CPU limited applications, and abstracting at the OS level creates a least common denominator effect. I don't much mind if my ICQ program is a little hefty (as long as the gain through abstraction offsets the performance hit) but if the OS causes my well-tuned 3D renderer to perform poorly, no amount of abstraction in the OS can justify it. The very reason people still use C for OS kernels is that it is almost as fast as ASM, and provides a decent amount of abstraction. Thinking that more CPU power entitles one to create more administrative overhead in the OS simply keeps the user from taking full advantage of his (often expensive) hardware. In concrete terms, if upgrading my CPU from 300MHz to 1200MHz results in a theoretical halving of rendering times, then I don't want my OS cutting in on that gain.
CPU effciency is only one of many criteria you can optimize for. And since more than 90% of computers spend more than 90% of their time idle, other things (like usability and development cost) are often more important.
>>>>>>>>
If you're CPU is 90% idle, you're wasting the power of the computer. You're also not doing video or audio editing and 3D animation.
Faster computers mean that we can increase the abbstraction layers between the hardware and the application to make it EASIER and FASTER to develop complex applications.
>>>>>>>>>
Yuck. Ugly UNIX thinking at its worst. Faster computers should allow you to do more, not devote more resources to administrative overhead.
That's really not very impressive. You should be able to play full screen video on anything over a pentium 200, accelerated video or no.
Actually, a nice solution to this is VBE/AF. There is an open implementation of this called FreeBE/AF, and basically what it does is provide a standard binary module that contains clean machine code. In other words, the drivers are completely self contained, and any OS can call the procedures in the driver without worrying about OS dependencies. To bad this idea hasn't caught on.
For all practical purposes, they do. They have to be open source in order to avoid the driver API of the day syndrome Linux has (or the company distributing them has to maintain dozens of different versions, like NVIDIA). In addition, the kernel developers are outwardly hostile to developers of closed source drivers (as evidenced by a recent kernel traffic thread) and the legal implications of closed source drivers linking to a GPL kernel are sketchy at best.
transparency, documentation and portability...
>>>>>>>>>
99% of the world doesn't consider network transparency a "basic feature." 99% of the world doesn't consider portability a feature. Windows GDI is more well-documented than X11.
X11 lacks such basic features as totally integrated anti-aliasing (extensions, in general, suck). X11 lacks a standard toolkit. X11 lacks high performance, low memory use, and low latency. Most people consider these to be far more important feature than the server or scientifically oriented "features" you specify.
I don't know about you, but spending an hour and a half compiling X is not my idea of fun...
Does that have DRI? Does that have all the extensions? Is that fully competitive with Windows2K in terms of features in addition to having network transparency? If so, why the hell is the X distribution 20MB of code?
Umm, does that mean X can't switch resolutions even when running a full-screen game or something? Meaning if I want to play Quake III at 800x600, I have to restart in that mode before starting the program?
Yea, and a lot of drivers require recompiling the kernel. Few drivers are distributed in binary form, and even when they are, they are usually specific to a particular (usually several months old) kernel version.
What the hell? I like BeOS! Is that a crime? Does that mean I'm a rabid Mac user out to destroy everything else? Hell, I even mention that Win2K is the *real* OS for 3D. How is that promoting BeOS? Or do Linux zealots think that all closed source OSs are interchangable?
PS> Dislaimer: Not all Mac users are rabid. Not all Linux users are zealots. Not all BeOS users are bitter.
I'd be cautious of having an opinion about something like that without hedging a bit. While I can see the point that private industry would be more efficient in implementing space programs, but I'd argue that it would lead to short-sightedness in research. Corporations are notoriously short-sighted (ex. AT&T not recognizing until 1998 that the internet would put long-distance carriers out of business) and space research could go from focusing on projects that have little immediate returns (but long term potential gains) to focusing on projects that can make a quick buck. I'd argue that a blend of both public and private research would be ideal, with a public agency like NASA focusing on long-term research (like studying comets, deep space, etc), and private companies focusing on short-term projects (like a moon base).