The real cost of new features is when they are actually used. Which they may be, may not be. They may not require any extra overhead above what they already cost as is. The cache miss stuff is trivial on a modern desktop: not so much because computers are fast, but because programmers really don't do much to mitigate cache issues.
But let's go more to the point. Let's say I have a command line program that does some sort of text manipulation, like sed. And let's say I add a new command line flag that makes sed do a completely different operation on its arguments. If that flag isn't used, the new code isn't used (except for the command-line option parser) and it's entirely possible that it may never even be paged in in the first place. Even if it is, it'll never make it to the cache. Yeah, it might change the cache usage of other parts a little, but that will be trivial compared to the cost of running sed on input using the old code.
Let's say I have an option that modifies the behavior of the existing code. Okay, that'll make some changes. There will probably be more if-statements. This will cause some branch prediction failures and some cache misses. Certainly, no doubt. But again, compared to the cost of running the regular code on the input, it's going to be insignificant. I'm sure you can imagine some edge cases where you get pathological behavior. I highly doubt all Ubuntu software is running up against a conspiracy of edge cases all across the desktop stack.
The point is, you can add features in a variety of ways (far more than I've mentioned here) without decreasing performance in any meaningful way. In fact, it's possible to add features while increasing performance. If the new features change the structure of the program in such a way that it's easier and more efficient to do the old stuff, then you will get a speed up. Refactoring can be a good thing.
They used plain out of the box installs for each test. Ubuntu hasn't seen a significant increase in the number of services over the past few releases (if it has indeed had any increases at all), so that shouldn't be a factor.
Those code paths don't have to be executed. So yes, they take up RAM (or maybe not if they never have to get paged in), but they will not slow other things down by simply existing.
The GTK+ statistics are mind-boggling slow. That's what I notice most when I use Ubuntu or Fedora. On my non-Ubuntu laptop, I get the following results for GTK performance:
GtkDrawingArea - Pixbufs: 3.73s (on mine) vs 43-55s (Ubuntu) GtkRadioButton: 13s vs 29-60s
I just think that's ridiculous. What did they do to GTK+ to make it so slow?
They haven't added any layers of abstraction over the past few releases. That isn't the problem anyways. I run Gentoo with the same bits of software, but it's not slow at all. And I'm not just talking about boot time. I mean, the UI is actually snappy and programs start up quickly. I don't know what Ubuntu does to make it so shitty, but they have done a really good job of it. Fedora on our workstations at work also seems to have suffered some severe performance regressions over the past few releases. Fedora 7 was pretty fast when we put it on. Now, at Fedora 9, the UI is painfully laggy and program startup is slow.
Look, you definitely don't want a closed priesthood of know-it-alls. That's bad and as you point out, it's had bad consequences in the past. On the other hand, you don't want people with little to no experience, who don't follow any sort of rigorous methodology, making up "knowledge". We've already seen what happens when that happens: urban legends, informercials and God knows what else. You have to strike a balance between keeping a field professional with caring and thoughtful practitioners. You want to have some barrier of entry, to keep out the true junk, but you also don't want a closed society. Anybody who cares enough should be able to get in and make a contribution. Again, it's balance. Opening the floodgates, or closing the doors completely -- neither of these are good solutions.
I didn't say PHP was great. But there are other "scripting" languages out there that do quite well and do have threads. Functional and dynamic languages like Lisp and co. have many of the features of scripting languages, but are technically compiled and perform quite well. Also, the threading models in C and C++ is extremely limited and easy to get wrong.
Let me know when C has closures and introspection. Sure, you can do it, but the result is so ugly and messy it severely obscures the meaning of the code. That, my friend, is the problem with C. Unless you really really need that last ounce of performance, or you are writing systems software, C is almost never a good choice.
A little elitism is a good thing. You don't want just people making judgments in fields that they know little to nothing about. That's where you get pseudo-science and superstition.
Don't you think this kind of research will help us better understand our own planet? After all, you don't get to understand how humans work by only studying humans. You study related -- and not so related -- animals and plants.
Well, if that is what he meant, then I think you have a fair point. I'm just so used to people saying blatantly incorrect things about the way language works that I probably assumed he meant the more ignorant of the two interpretations.
As someone with a BA in Linguistics, I call BS on the natural language part of your post. The biggest mistake you have made is that you failed to distinguish between written grammar guides, and an actual grammar for a language, which is in each person's head and is quite complete and well-formed. So much so that we have yet to fully elucidate the complexities therein.
Uhh, no. Because the virtual memory for a real file that is memory mapped is backed by the file itself, not the swapspace. The swapspace is ONLY used for pages that are not mapped to actual files and then only when those pages must be evicted from RAM due to low memory conditions.
If you map an 80GB file, the pages are associated with the file itself. When you access part of the mapping, the pages are brought in to page frames in RAM. If they are modified, and then need to be evicted, then they are written back out to the file. Otherwise, the frames are discarded outright. Nowhere in that process is swap required. Indeed, it would be stupid to copy the contents of any file to swap (which is effectively just another file) before using it.
Uhh...no. As long as your process has enough virtual memory space (which 64-bit processes most certainly do), you can map as much as you want. You can't get away with mapping more anonymous/private mappings than you have physical + swap because those mappings have to be backed by physical RAM or swap (other mappings are backed by files on the disk). You can overcommit, however, if all of those mappings won't be used at once. Dangerous that is.
Only private and/or anonymous mappings are put into the swap file. Shared mappings (e.g., program text segments, libraries, etc.) can be discarded from RAM and reloaded directly from the files they came from in the first place. In fact, this is how they are loaded in the first place. So you aren't saving much by not having a swap partition unless you have an absolutely huge amount of private or anonymous mappings in use by your mostly idle services.
Thank you. I have an x300 in a Thinkpad T43 and while the first year was rough, the OSS drivers have improved markedly. 2d performance is nearly on par with Windows, and is actually quite snappy with xcompmgr running. Compiz is also fairly fast these days, although still slower than a plain old desktop. X is rock solid stable, even using git for the entire X setup (I haven't had a random server crash once). And every week or so, I see a new set of commits that improve performance for r300 or EXA. It just keeps getting better. Meanwhile, I see people on forums complaining about how to get nVidia drivers working, and how the kernel is always locking up etc. Granted, it's not a whole lot worse or better than fglrx generally has been, but for nVidia users, that's really the only option. The OSS drivers are either horribly out of date (nv) or a work in progress (nouveau). I am now glad that I ended up with an ATI card instead of nVidia. It was worth the wait.
As an anxiety sufferer, I can tell you that breathing your way through panic or anxiety does not work in the general case. Sometimes, you really need medication. I find benzodiazepines to be much more effective than beta blockers (and anti-depressants even more so). A lot of people complain about benzos being addictive, but if you take proper doses, wean off them correctly and get proper therapy, it's not a problem. I've talked to so many people who were at one time or another on sometimes even high doses of benzos and a year or two later they were on nothing and doing better than they ever had before. Of course, some people just take the benzos and do nothing else and then of course they end up truly addicted.
Slashdot Mirror
We have sub $500 Dell workstations with integrated Intel graphics. That may be the main problem.
The real cost of new features is when they are actually used. Which they may be, may not be. They may not require any extra overhead above what they already cost as is. The cache miss stuff is trivial on a modern desktop: not so much because computers are fast, but because programmers really don't do much to mitigate cache issues. But let's go more to the point. Let's say I have a command line program that does some sort of text manipulation, like sed. And let's say I add a new command line flag that makes sed do a completely different operation on its arguments. If that flag isn't used, the new code isn't used (except for the command-line option parser) and it's entirely possible that it may never even be paged in in the first place. Even if it is, it'll never make it to the cache. Yeah, it might change the cache usage of other parts a little, but that will be trivial compared to the cost of running sed on input using the old code. Let's say I have an option that modifies the behavior of the existing code. Okay, that'll make some changes. There will probably be more if-statements. This will cause some branch prediction failures and some cache misses. Certainly, no doubt. But again, compared to the cost of running the regular code on the input, it's going to be insignificant. I'm sure you can imagine some edge cases where you get pathological behavior. I highly doubt all Ubuntu software is running up against a conspiracy of edge cases all across the desktop stack. The point is, you can add features in a variety of ways (far more than I've mentioned here) without decreasing performance in any meaningful way. In fact, it's possible to add features while increasing performance. If the new features change the structure of the program in such a way that it's easier and more efficient to do the old stuff, then you will get a speed up. Refactoring can be a good thing.
Cache misses if the code is used. If it's not, it incurs no penalty except for the piddly bit of space it uses on the harddrive.
No it DOESN'T have to run if that feature is never used. I don't know why this is so hard to understand.
They used plain out of the box installs for each test. Ubuntu hasn't seen a significant increase in the number of services over the past few releases (if it has indeed had any increases at all), so that shouldn't be a factor.
Those code paths don't have to be executed. So yes, they take up RAM (or maybe not if they never have to get paged in), but they will not slow other things down by simply existing.
The GTK+ statistics are mind-boggling slow. That's what I notice most when I use Ubuntu or Fedora. On my non-Ubuntu laptop, I get the following results for GTK performance:
GtkDrawingArea - Pixbufs: 3.73s (on mine) vs 43-55s (Ubuntu)
GtkRadioButton: 13s vs 29-60s
I just think that's ridiculous. What did they do to GTK+ to make it so slow?
They haven't added any layers of abstraction over the past few releases. That isn't the problem anyways. I run Gentoo with the same bits of software, but it's not slow at all. And I'm not just talking about boot time. I mean, the UI is actually snappy and programs start up quickly. I don't know what Ubuntu does to make it so shitty, but they have done a really good job of it. Fedora on our workstations at work also seems to have suffered some severe performance regressions over the past few releases. Fedora 7 was pretty fast when we put it on. Now, at Fedora 9, the UI is painfully laggy and program startup is slow.
Look, you definitely don't want a closed priesthood of know-it-alls. That's bad and as you point out, it's had bad consequences in the past. On the other hand, you don't want people with little to no experience, who don't follow any sort of rigorous methodology, making up "knowledge". We've already seen what happens when that happens: urban legends, informercials and God knows what else. You have to strike a balance between keeping a field professional with caring and thoughtful practitioners. You want to have some barrier of entry, to keep out the true junk, but you also don't want a closed society. Anybody who cares enough should be able to get in and make a contribution. Again, it's balance. Opening the floodgates, or closing the doors completely -- neither of these are good solutions.
I didn't say PHP was great. But there are other "scripting" languages out there that do quite well and do have threads. Functional and dynamic languages like Lisp and co. have many of the features of scripting languages, but are technically compiled and perform quite well. Also, the threading models in C and C++ is extremely limited and easy to get wrong.
Let me know when C has closures and introspection. Sure, you can do it, but the result is so ugly and messy it severely obscures the meaning of the code. That, my friend, is the problem with C. Unless you really really need that last ounce of performance, or you are writing systems software, C is almost never a good choice.
Perl once used "'" to separate package name parts. Still does for backwards compatibility. Really annoying. Oops! I love Perl, btw.
I thought scientific progress was the name of the game?
A little elitism is a good thing. You don't want just people making judgments in fields that they know little to nothing about. That's where you get pseudo-science and superstition.
Don't you think this kind of research will help us better understand our own planet? After all, you don't get to understand how humans work by only studying humans. You study related -- and not so related -- animals and plants.
Well, if that is what he meant, then I think you have a fair point. I'm just so used to people saying blatantly incorrect things about the way language works that I probably assumed he meant the more ignorant of the two interpretations.
As someone with a BA in Linguistics, I call BS on the natural language part of your post. The biggest mistake you have made is that you failed to distinguish between written grammar guides, and an actual grammar for a language, which is in each person's head and is quite complete and well-formed. So much so that we have yet to fully elucidate the complexities therein.
Uhh, no. Because the virtual memory for a real file that is memory mapped is backed by the file itself, not the swapspace. The swapspace is ONLY used for pages that are not mapped to actual files and then only when those pages must be evicted from RAM due to low memory conditions.
If you map an 80GB file, the pages are associated with the file itself. When you access part of the mapping, the pages are brought in to page frames in RAM. If they are modified, and then need to be evicted, then they are written back out to the file. Otherwise, the frames are discarded outright. Nowhere in that process is swap required. Indeed, it would be stupid to copy the contents of any file to swap (which is effectively just another file) before using it.
Uhh...no. As long as your process has enough virtual memory space (which 64-bit processes most certainly do), you can map as much as you want. You can't get away with mapping more anonymous/private mappings than you have physical + swap because those mappings have to be backed by physical RAM or swap (other mappings are backed by files on the disk). You can overcommit, however, if all of those mappings won't be used at once. Dangerous that is.
Only private and/or anonymous mappings are put into the swap file. Shared mappings (e.g., program text segments, libraries, etc.) can be discarded from RAM and reloaded directly from the files they came from in the first place. In fact, this is how they are loaded in the first place. So you aren't saving much by not having a swap partition unless you have an absolutely huge amount of private or anonymous mappings in use by your mostly idle services.
Yes, let's go back to the days of overlays and manual management of transferring data to and from disks and other devices. That was so much simpler.
Uhh, yes it is. I can't find a single reference online that indicates otherwise. It most certainly is not the "void main()" travesty.
No, because the words are pronounced the same, thanks to the fact that in English, the vowels in unstressed syllables are reduced to schwas.
Thank you. I have an x300 in a Thinkpad T43 and while the first year was rough, the OSS drivers have improved markedly. 2d performance is nearly on par with Windows, and is actually quite snappy with xcompmgr running. Compiz is also fairly fast these days, although still slower than a plain old desktop. X is rock solid stable, even using git for the entire X setup (I haven't had a random server crash once). And every week or so, I see a new set of commits that improve performance for r300 or EXA. It just keeps getting better. Meanwhile, I see people on forums complaining about how to get nVidia drivers working, and how the kernel is always locking up etc. Granted, it's not a whole lot worse or better than fglrx generally has been, but for nVidia users, that's really the only option. The OSS drivers are either horribly out of date (nv) or a work in progress (nouveau). I am now glad that I ended up with an ATI card instead of nVidia. It was worth the wait.
As an anxiety sufferer, I can tell you that breathing your way through panic or anxiety does not work in the general case. Sometimes, you really need medication. I find benzodiazepines to be much more effective than beta blockers (and anti-depressants even more so). A lot of people complain about benzos being addictive, but if you take proper doses, wean off them correctly and get proper therapy, it's not a problem. I've talked to so many people who were at one time or another on sometimes even high doses of benzos and a year or two later they were on nothing and doing better than they ever had before. Of course, some people just take the benzos and do nothing else and then of course they end up truly addicted.