Re:This is This is the exact opposite of my findin
on
New Linux 2.5 Benchmarks
·
· Score: 5, Informative
Um, doing benchmarks between an Athlon XP and a Pentium 4 is folly. The P4 has notoriously slow context switching performance. Also, if you are running a small number of threads, your computer isn't spending a whole lot of time thread switching anyway, so the hit doesn't really affect you. When you have lots of threads, scheduling becomes far more important, and so the increase is much more noticible.
That's really not true. In a lot of countries, trade is very one-sided, and it only hurts the country. Take countries around the Indian subcontinent. In those countries, there is a small upper class with a significant amount of spending power. However, they tend to spend most of their money on foreign products, so instead of the money having a "trickle-down" effect (as Reagen-ites like to call it) it just leaves the economy entirely. On the other hand, those countries don't sell nearly enough to make up for what they buy. As a result, money continually leaves those countries, instead of staying within them. Trade is only helpful when it's really "trade," implying an equal exchange on both sides. This, btw, is one reason (of many) people are afraid of globalization. Countries (especially the US*) and others tend to open up markets for their products, rather than creating mutually benificial two-way relationships.
*> I'm not saying, btw, that this is a negative intention on the part of these countries. It's just that the US is self-sufficient in most things (food, etc) so we have a lot to sell, but not a whole lot to buy.
Well in my case, I always make sure to get huge amounts of RAM, so hard-drive is usually not an issue. For example, moving from my 1.5 GHz Athlon to my 2GHz P4 actually had a noticible benifet for me. Many KDE apps seem to be CPU bound. Particularly, Konqueror pegs the CPU while reformatting HTML pages, and all KDE apps start out by processing 60,000 relocations. The faster CPU reduced the redraw problems, and apps started up faster. A huge difference? Of course not, but enough to notice it.
PS> Now, upgrading for 500 more megahertz (essentially similar end-level performance, though) was not pure wantonness. I moved from a desktop to a laptop.
Actually, downloading music for free has nothing to do with it. DRM just plain sucks. I bought a Sony NetMD player a while ago. Great little device. I personally think MiniDisc rules. But it's got DRM crap built in, and is thus nearly impossible to reverse engineer the protocol. As a result, I can only use it in Windows. My $150 player is now just a piece of plastic. Am I ever going to buy another audio player from Sony again? Not likely.
I've said this before a couple of times, but it's particularly relevent. Thsese services need to make their content accessible. I recently *bought* a subscription to Rhapsody, which is currently the biggest online music site (aside from maybe eMusic, but Rhapsody carries big-5 stuff). I was perfectly happy to shell out $10 or $20 bucks a month (note, I buy about 1 CD a year, so this is 12x the amount they usually get for me). I considered it a pretty fair deal. Then, I found out that you could only use it with Internet Explorer, and only on Windows. Windows is my dedicated CounterStrike OS. I've got like 100MB free once XP and HalfLife is installed. Screw them if they think I'd boot back into Windows just to use their service. For a streaming media website, this makes no sense at all. So in the end, I decided that Shoutcast was good enough for me, and cancled my subscription. While the number of Linux users out there is comparatively small, the number of MacOS users isn't. And I'd tend to bet that the MacOS-types are significantly more likely than the average Windows user to subscribe to something like this. Also, a lot of desktop Linux users are on the younger side, and they'd also be more likely to buy into this. All told, there is probably a pretty nice chunk of change that they're losing from being uni-platform. Especially since it takes *less* development effort to just use the browser and native media systems thatn to roll your own!
Further, if you search for "Linux bugs" on Usenet, you get 571,000 hits. If you search for "Windows bugs" you get 389,000 hits. Of course, this can only mean one thing: *BSD is dying...
I never said I can't read and respond to them. I said that it's not fast enough. Fast enough, for me, is when everything is instant. When I can resize windows like crazy and never, ever, detect a hint of redraw. In real life, if I shove my calculator across my desk, it doesn't visibly redraw. Why should my windows be any different? I mean, Konqueror and KMail are usable for me, don't get me wrong. I'd even say it's pretty peppy. But is it fast enough? No.
Um, what's a small typecase? For reference, on a 300Mhz PII with Visual C++ 6.0, a virtual function call is 10x slower than a regular function call. Significant, but you don't make virtual function calls all that often (like you wouldn't put one in an inner loop of a math routine, that's what templates are for!)
Oh, and people who actually do, say work on their computers, need the horsepower. When you add up all the people that do architecture, engineering, computational science, video/audio editing, desktop publishing, etc, that's a very significant percentage of the computer using population. Certainly enough to sustain some profit-margins for high-end chips like this. And that's without the gamers...
..sigh... Every time one of these articles come out. First, if you can't tell the difference between 2GHz and 600MHz, you're dead. My 2GHz machine is nowhere near fast enough, even just running Konqueror and KMail. Second, more people need the power than you'd think. I write C++ code with some very heavily templated libraries. G++ eats my processor for lunch (I've got enough RAM that it's not HD-bound). Add to that 3D rendering (messing around with Blender for some 3D work) and numerical computation (simulations, Octave, Mathematica) and I probably won't ever have enough CPU. And I don't even do gaming!
Every single compiler I know of uses v-tables. Sure you can't guarantee that behavior, but the basic guarantee (not by standard but by convention) is that using a virtual function is as cheap as deferencing a pointer to a function. That's all you really need to know, until a bug turns up at which point you can just consult your compiler manual. But the key idea is that you can ignore it until you can't anymore, instead of having to pay attention to it all the time.
I just thought of another reason why abstractions are important. Take the famous MP3 -> Ogg conversion. Semantically, many aspects of the two types don't match, so the resulting conversion is less than perfect. Well, the Brain -> Machine Code conversion is something more akin to an MP3 -> PDF scenario. And for that reason, programming in a low level language (for scopes big enough to trash the mental cache, so to speak) has a similar conversion problem. Human beings things at an extremely high level, and can manipulate thousand-layer abstractions with ease (think of, for example, the abstraction of a 'cat'). Even something considered high-level in the programming world (objects and generic algorithms) are low-level to human beings. The ideal abstraction, would be, of course, natural language. Human beings think in natural language, and translating thoughts into natural language is trivially easy. For example, I'm writing a linker at the moment. I'd just like to be able to say:
Sort sections by name. Remove all duplicate sections that have the LINK_ONCE parameter set. Merge all other duplicate sections. For each relocation in the relocation table, find the corresponding symbol and update the necessary address. Merge string tables, and update all string references. Write sections to this file.
There we go, six "lines of code." Very close mapping between my thoughts and the code. Assuming the compiler carries out my instructions faithfully, what are the chances of a bug in this code? Nearly zero. It's quite easy to verify that six lines of code is logically correct. Verifying that the thousands of lines of C++ that this translates to is both logically and semantically correct is much, much, harder.
Not so. Using low level abstractions is manual and error prone. The compiler is far better at micromanaging, so why not let the compiler do the work? Take C++ templates for example. They are a very high-level construct, but generate code that is often better than hand-tuned C (for scientific programs, for example, or stuff like qsort or standardized datastructures). Then take stuff like virtual functions. FreeBSD uses something exactly like virtual functions in its driver code. You got bits like this:
struct driver_ops {
int (*init)(int param);
int(*do_stuff)(int param);
int (*cleanup)(int param); };
struct driver {...
driver_ops * ops;... };
This construct generates the *exact* same code as
class driver_iface {
public:
virtual int init(int param)=0;
virtual int do_stuff(int param)=0;
virtual int cleanup(int param)=0;
private:... };
class driver_imp:public driver_iface {
public:/* override pure virtual functions */... };
Do you think that using the first construct (which is dangerous and requires you to initialize the functions pointers correctly) is any better than the second? I agree with you to the extent that you should *know* how to work in the low-level, to fix bugs as they arise. But you should work in the high-level, to make sure that tedium and micromanagement doesn't get the better of you.
PS> As for the FreeBSD vs WinXP or OS X comment, that's useless. First, all the kernels are written in C (except for OS X which uses the aformentioned C++ construct in drivers). Second, it's always the algorithms that are more important than anything else. FreeBSD simply has better algorithms. To the extent that a high-level language allows you to focus on your algorithms rather than micromanagement, they're even better than low level code.
The next generation of Java will support generics, and I'd like to see Java do generics justice. Meaning, I'd like to see Java use it's position as a new language with a significant runtime to make C++ generics better. For example, Java generics could store a type-independent representation of code and automatically instantiating templates at runtime, so dynamically loaded modules could make better use of generic functions. I'd like to see them actually make Java do something C++ can't, instead of adding another long list of features C++ gives you permission to do and Java doesn't.
Hm, it Pascal strings would make strcmp() slower, though, because of the overhead of maintaining a loop counter and checking it against the string length. I'd argue that you spend just as much time comparing strings as copying them around, so it's 6 of one or a half dozen of the other...
As for string literals, who uses string literals? Most text should be stored externally to allow for translations, and what few string literals there are aren't performance intensive at all. They hardly justify changing such a critical semantic in C/C++.
strlen becomes O(1) but strcat is still O(n) and strcpy is still O(n). I really don't think strlen() is performance intensive enough to justify the performance decrease. Besides, a string class could easily implement Pascal-like strings instead of C-style ones, without having it be a built in type.
Um, how exactly would a native string type save you overhead? They'd be null-terminated strings underneath anyway. I can't imagine implementing something more efficient than null terminated strings (for short strings, of course, you should be using something like ropes for megabytes of text). If you could, you could do it in C anyway. Could you clarify?
While I usually like Joel's work, I'm pissed about the random jab at C++. For those he didn't read the article, he says something along the lines of
"A lot of the stuff the C++ committe added to the language was to support a string class. Why didn't they just add a built-in string type?"
It's good that a string class wasn't added, because that lead to templates being added! And templates are the greatest thing, ever!
The comment shows a total lack of understanding of post-template, modern C++. People are free not to like C++ (or aspects of it) and to disagree with me about templates, of course, and in that case I'm fine with them taking stabs at it. But I get peeved when people who have just given the language a cursory glance try to fault it. If you haven't used stuff like Loki or Boost, or taken a look at some of the fascinating new design techniques that C++ has enabled, then you're in no place to comment about the language. At least read something like the newer editions of D&E or "The C++ Programming Language" then read "Modern C++" before spouting off.
PS> Of course, I'm not accusing the author of being unknowledgable about C++ or anything of the sort. I'm just saying that this particular comment sounded rather n00b'ish, so to speak.
1) Content is king. 2) Alternative OSs are usable largely because current file formats are decodable, and alternate OS users can still view said content. 3) Palladium allows people to control their own content. 4) Microsoft can default their products to Palladium-on, but no restrictions. Most Word-using idiots wouldn't notice, because all their Word-using friends can still read it. Don't think that the sheep are concious enough to disable Palladium to make their content free. I mean, even major websites have no problem requiring Internet Explorer, for god sakes! 5) Media companies flock to Palladium, of course, release their content under its protection. 6) Suddenly, most content is Palladium protected, and an OS isn't viable without supporting Palladium.
6 steps. That's all it takes. People who have a clue aren't afraid that DRM-hardware will disallow running other OSs. People are afraid that the aformentioned set of events will take place. And seriously, do you think any of them are very far-fetched at all? Are any of them even unlikely? Hell, I'm beginning to see it already. I tried to subscribe to Rhapsody, the online music site, but their streaming software and protocol is closed (to prevent people recording) and Windows-only.
I probably dislike it because I'm learned C++ first. Hungarian notation just isn't popular in C++ circles. That aside, it also probably has something to do with it's association to the phenomenally bad naming conventions of Windows code. You've got stuff like ALLCAPSSTRUCTURENAMESWITHOUTSPACES, member variable prefixes half a dozen characters long, random made up acronyms, ugh... Windows code is phenomenally difficult to read, and Hungarian notation doesn't make things any clearer.
Slashdot Mirror
Um, doing benchmarks between an Athlon XP and a Pentium 4 is folly. The P4 has notoriously slow context switching performance. Also, if you are running a small number of threads, your computer isn't spending a whole lot of time thread switching anyway, so the hit doesn't really affect you. When you have lots of threads, scheduling becomes far more important, and so the increase is much more noticible.
That's really not true. In a lot of countries, trade is very one-sided, and it only hurts the country. Take countries around the Indian subcontinent. In those countries, there is a small upper class with a significant amount of spending power. However, they tend to spend most of their money on foreign products, so instead of the money having a "trickle-down" effect (as Reagen-ites like to call it) it just leaves the economy entirely. On the other hand, those countries don't sell nearly enough to make up for what they buy. As a result, money continually leaves those countries, instead of staying within them. Trade is only helpful when it's really "trade," implying an equal exchange on both sides. This, btw, is one reason (of many) people are afraid of globalization. Countries (especially the US*) and others tend to open up markets for their products, rather than creating mutually benificial two-way relationships.
*> I'm not saying, btw, that this is a negative intention on the part of these countries. It's just that the US is self-sufficient in most things (food, etc) so we have a lot to sell, but not a whole lot to buy.
Obviously, whoever modded me down never browses at -1, and has never seen a *BSD is dying troll...
Well in my case, I always make sure to get huge amounts of RAM, so hard-drive is usually not an issue. For example, moving from my 1.5 GHz Athlon to my 2GHz P4 actually had a noticible benifet for me. Many KDE apps seem to be CPU bound. Particularly, Konqueror pegs the CPU while reformatting HTML pages, and all KDE apps start out by processing 60,000 relocations. The faster CPU reduced the redraw problems, and apps started up faster. A huge difference? Of course not, but enough to notice it.
PS> Now, upgrading for 500 more megahertz (essentially similar end-level performance, though) was not pure wantonness. I moved from a desktop to a laptop.
Actually, downloading music for free has nothing to do with it. DRM just plain sucks. I bought a Sony NetMD player a while ago. Great little device. I personally think MiniDisc rules. But it's got DRM crap built in, and is thus nearly impossible to reverse engineer the protocol. As a result, I can only use it in Windows. My $150 player is now just a piece of plastic. Am I ever going to buy another audio player from Sony again? Not likely.
I've said this before a couple of times, but it's particularly relevent. Thsese services need to make their content accessible. I recently *bought* a subscription to Rhapsody, which is currently the biggest online music site (aside from maybe eMusic, but Rhapsody carries big-5 stuff). I was perfectly happy to shell out $10 or $20 bucks a month (note, I buy about 1 CD a year, so this is 12x the amount they usually get for me). I considered it a pretty fair deal. Then, I found out that you could only use it with Internet Explorer, and only on Windows. Windows is my dedicated CounterStrike OS. I've got like 100MB free once XP and HalfLife is installed. Screw them if they think I'd boot back into Windows just to use their service. For a streaming media website, this makes no sense at all. So in the end, I decided that Shoutcast was good enough for me, and cancled my subscription. While the number of Linux users out there is comparatively small, the number of MacOS users isn't. And I'd tend to bet that the MacOS-types are significantly more likely than the average Windows user to subscribe to something like this. Also, a lot of desktop Linux users are on the younger side, and they'd also be more likely to buy into this. All told, there is probably a pretty nice chunk of change that they're losing from being uni-platform. Especially since it takes *less* development effort to just use the browser and native media systems thatn to roll your own!
Further, if you search for "Linux bugs" on Usenet, you get 571,000 hits. If you search for "Windows bugs" you get 389,000 hits. Of course, this can only mean one thing: *BSD is dying...
I never said I can't read and respond to them. I said that it's not fast enough. Fast enough, for me, is when everything is instant. When I can resize windows like crazy and never, ever, detect a hint of redraw. In real life, if I shove my calculator across my desk, it doesn't visibly redraw. Why should my windows be any different? I mean, Konqueror and KMail are usable for me, don't get me wrong. I'd even say it's pretty peppy. But is it fast enough? No.
It's not just code bloat. Perhaps it's more along the lines of "what user's want to do with their hardware is more than the hardware allows."
125 watts per die, 4 die per module, so north of 500 watts (thanks to the 128MB of L3 cache) per module.
Um, what's a small typecase? For reference, on a 300Mhz PII with Visual C++ 6.0, a virtual function call is 10x slower than a regular function call. Significant, but you don't make virtual function calls all that often (like you wouldn't put one in an inner loop of a math routine, that's what templates are for!)
Wow. 100 watts. One whole lightbulb. Big whoop. The Power4 sucks on the better part of a kilowatt. Now that's rather significant.
Oh, and people who actually do, say work on their computers, need the horsepower. When you add up all the people that do architecture, engineering, computational science, video/audio editing, desktop publishing, etc, that's a very significant percentage of the computer using population. Certainly enough to sustain some profit-margins for high-end chips like this. And that's without the gamers...
..sigh... Every time one of these articles come out. First, if you can't tell the difference between 2GHz and 600MHz, you're dead. My 2GHz machine is nowhere near fast enough, even just running Konqueror and KMail. Second, more people need the power than you'd think. I write C++ code with some very heavily templated libraries. G++ eats my processor for lunch (I've got enough RAM that it's not HD-bound). Add to that 3D rendering (messing around with Blender for some 3D work) and numerical computation (simulations, Octave, Mathematica) and I probably won't ever have enough CPU. And I don't even do gaming!
Every single compiler I know of uses v-tables. Sure you can't guarantee that behavior, but the basic guarantee (not by standard but by convention) is that using a virtual function is as cheap as deferencing a pointer to a function. That's all you really need to know, until a bug turns up at which point you can just consult your compiler manual. But the key idea is that you can ignore it until you can't anymore, instead of having to pay attention to it all the time.
I just thought of another reason why abstractions are important. Take the famous MP3 -> Ogg conversion. Semantically, many aspects of the two types don't match, so the resulting conversion is less than perfect. Well, the Brain -> Machine Code conversion is something more akin to an MP3 -> PDF scenario. And for that reason, programming in a low level language (for scopes big enough to trash the mental cache, so to speak) has a similar conversion problem. Human beings things at an extremely high level, and can manipulate thousand-layer abstractions with ease (think of, for example, the abstraction of a 'cat'). Even something considered high-level in the programming world (objects and generic algorithms) are low-level to human beings. The ideal abstraction, would be, of course, natural language. Human beings think in natural language, and translating thoughts into natural language is trivially easy. For example, I'm writing a linker at the moment. I'd just like to be able to say:
Sort sections by name.
Remove all duplicate sections that have the LINK_ONCE parameter set.
Merge all other duplicate sections.
For each relocation in the relocation table, find the corresponding symbol and update the necessary address.
Merge string tables, and update all string references.
Write sections to this file.
There we go, six "lines of code." Very close mapping between my thoughts and the code. Assuming the compiler carries out my instructions faithfully, what are the chances of a bug in this code? Nearly zero. It's quite easy to verify that six lines of code is logically correct. Verifying that the thousands of lines of C++ that this translates to is both logically and semantically correct is much, much, harder.
Not so. Using low level abstractions is manual and error prone. The compiler is far better at micromanaging, so why not let the compiler do the work? Take C++ templates for example. They are a very high-level construct, but generate code that is often better than hand-tuned C (for scientific programs, for example, or stuff like qsort or standardized datastructures). Then take stuff like virtual functions. FreeBSD uses something exactly like virtual functions in its driver code. You got bits like this:
... ...
...
:public driver_iface /* override pure virtual functions */ ...
struct driver_ops
{
int (*init)(int param);
int(*do_stuff)(int param);
int (*cleanup)(int param);
};
struct driver
{
driver_ops * ops;
};
This construct generates the *exact* same code as
class driver_iface
{
public:
virtual int init(int param)=0;
virtual int do_stuff(int param)=0;
virtual int cleanup(int param)=0;
private:
};
class driver_imp
{
public:
};
Do you think that using the first construct (which is dangerous and requires you to initialize the functions pointers correctly) is any better than the second? I agree with you to the extent that you should *know* how to work in the low-level, to fix bugs as they arise. But you should work in the high-level, to make sure that tedium and micromanagement doesn't get the better of you.
PS> As for the FreeBSD vs WinXP or OS X comment, that's useless. First, all the kernels are written in C (except for OS X which uses the aformentioned C++ construct in drivers). Second, it's always the algorithms that are more important than anything else. FreeBSD simply has better algorithms. To the extent that a high-level language allows you to focus on your algorithms rather than micromanagement, they're even better than low level code.
C++ version:
int main()
{
char * buf=reinterpret_cast(0xB8000);
*buf='A';
return 0;
}
With GCC 3.2 at -O3, this compiles to 22 bytes, including function setup code and instruction alignment.
The next generation of Java will support generics, and I'd like to see Java do generics justice. Meaning, I'd like to see Java use it's position as a new language with a significant runtime to make C++ generics better. For example, Java generics could store a type-independent representation of code and automatically instantiating templates at runtime, so dynamically loaded modules could make better use of generic functions. I'd like to see them actually make Java do something C++ can't, instead of adding another long list of features C++ gives you permission to do and Java doesn't.
Hm, it Pascal strings would make strcmp() slower, though, because of the overhead of maintaining a loop counter and checking it against the string length. I'd argue that you spend just as much time comparing strings as copying them around, so it's 6 of one or a half dozen of the other...
As for string literals, who uses string literals? Most text should be stored externally to allow for translations, and what few string literals there are aren't performance intensive at all. They hardly justify changing such a critical semantic in C/C++.
strlen becomes O(1) but strcat is still O(n) and strcpy is still O(n). I really don't think strlen() is performance intensive enough to justify the performance decrease. Besides, a string class could easily implement Pascal-like strings instead of C-style ones, without having it be a built in type.
Um, how exactly would a native string type save you overhead? They'd be null-terminated strings underneath anyway. I can't imagine implementing something more efficient than null terminated strings (for short strings, of course, you should be using something like ropes for megabytes of text). If you could, you could do it in C anyway. Could you clarify?
While I usually like Joel's work, I'm pissed about the random jab at C++. For those he didn't read the article, he says something along the lines of
"A lot of the stuff the C++ committe added to the language was to support a string class. Why didn't they just add a built-in string type?"
It's good that a string class wasn't added, because that lead to templates being added! And templates are the greatest thing, ever!
The comment shows a total lack of understanding of post-template, modern C++. People are free not to like C++ (or aspects of it) and to disagree with me about templates, of course, and in that case I'm fine with them taking stabs at it. But I get peeved when people who have just given the language a cursory glance try to fault it. If you haven't used stuff like Loki or Boost, or taken a look at some of the fascinating new design techniques that C++ has enabled, then you're in no place to comment about the language. At least read something like the newer editions of D&E or "The C++ Programming Language" then read "Modern C++" before spouting off.
PS> Of course, I'm not accusing the author of being unknowledgable about C++ or anything of the sort. I'm just saying that this particular comment sounded rather n00b'ish, so to speak.
Go through the my premises:
1) Content is king.
2) Alternative OSs are usable largely because current file formats are decodable, and alternate OS users can still view said content.
3) Palladium allows people to control their own content.
4) Microsoft can default their products to Palladium-on, but no restrictions. Most Word-using idiots wouldn't notice, because all their Word-using friends can still read it. Don't think that the sheep are concious enough to disable Palladium to make their content free. I mean, even major websites have no problem requiring Internet Explorer, for god sakes!
5) Media companies flock to Palladium, of course, release their content under its protection.
6) Suddenly, most content is Palladium protected, and an OS isn't viable without supporting Palladium.
6 steps. That's all it takes. People who have a clue aren't afraid that DRM-hardware will disallow running other OSs. People are afraid that the aformentioned set of events will take place. And seriously, do you think any of them are very far-fetched at all? Are any of them even unlikely? Hell, I'm beginning to see it already. I tried to subscribe to Rhapsody, the online music site, but their streaming software and protocol is closed (to prevent people recording) and Windows-only.
I probably dislike it because I'm learned C++ first. Hungarian notation just isn't popular in C++ circles. That aside, it also probably has something to do with it's association to the phenomenally bad naming conventions of Windows code. You've got stuff like ALLCAPSSTRUCTURENAMESWITHOUTSPACES, member variable prefixes half a dozen characters long, random made up acronyms, ugh... Windows code is phenomenally difficult to read, and Hungarian notation doesn't make things any clearer.