The PS2 has two vector coprocessors running at 300Mhz too, though only one of them is really useful for anything. Because of Sony's general philosophy of putting a bunch of weird specialty hardware in their machines, you can't just list CPU clock rates (as relevant as that ever is to anything).
The XBox is clearly more powerful than the PS2 (though not by as much as you suggest), but the GameCube isn't.
Where the XBox, the 360, and the Wii have the biggest advantage is that they're relatively easy to program for. Writing software for specialized vector processors is a pain.
RAID5 has terrible random write performance, because every write causes a write to every disk in the array.
XanC:
I have to read from _every drive in the array_ in order to do a write, because the parity has to be calculated. Note that it's not the calculation that's slow, it's getting the data for it. So that's multiple operations to do a simple write.
No it does not. An x+1 parity computation only requires the parity block and the block being overwritten to write the new block. You take the parity, "subtract" the old data, and "add" the new data (in fact, the "subtract" and "add" are both just XOR).
Alternatively, if you're writing a full stripe, you can just compute the parity directly. This is of course preferable to doing reads, since reads are slow. Your random write performance is suffering because you have to read and write exactly two disks in the stripe.
I don't know why this old myth comes up so often. Any decent reference will explain how parity works. Maybe if Kari Byron explained RAID parity striping, it would sink in?
Doing random reads is not slow for an SSD, so of course the random write performance with RAID 5 will be much better with SSDs.
Boot time for an OS is measured from boot loader to usable system, not from power button. This is a different measurement from boot time for a whole computer system.
Why the distinction?
Well, for example, Linux can't do anything if your BIOS sucks. It could boot in half a second, but it'll still take 90 seconds to get to the boot loader. What this means is that you use the OS time when comparing operating systems.
When comparing a Mac to an Dell computer, you compare the OS and the hardware boot time together, because Apple and Dell can actually fix that BIOS stuff if you complain enough.
So, the poster above was right to compare OSX to Ubuntu using the time from boot loader.
Broaden your vision. This is about making smaller components.
What can you do with smaller components? Well, right away, you can put more stuff in the case. Your iphonanopalmtop thing can have a foldout screen and keyboard, or a bigger battery, or it can simply be lighter. I don't know about you, but I find an iPhone a bit hefty.
Now, if you look beyond next week, smaller components let you do entirely new things. You think technology is sufficient now to put a computer in a palmtop? Whatever, dude.
I want a computer in my eyeglasses. Optically corrected screens overlaying my vision. High resolution. And I want them to weigh the same as a normal pair of glasses. Don't forget to throw in a video camera for good measure.
Can we build something like that now? Or course not. That sort of thing today is either a huge bulky piece of headgear, or it's moderately bulky and has a terrible display. We need better components: much smaller, much lower power, faster.
Don't ever say we've reached the limits of useful computer technology. Until you're plugged in directly via your visual cortex and have a robot butler who brings you waffles in the morning, we haven't even reached the limits of uses we can already imagine.
I heard on TV that an omnipotent sky monkey plans to torture us all in a volcano forever because some woman made out of a guy's rib ate a snack with a talking snake.
Because there's no reasonable alternative yet. Konqueror crashes too, and has a lot of trouble making flash work properly. Opera doesn't work well either.
And of course, it's always a pain to have to constantly override the browser ID with whatever bullshit everyone's bozo website requires.
This is so much ado about nothing. I can count on one hand the number of times I've had a problem with Firefox that would have been solved by it being in its own process.
Funny. Firefox crashes every single day for me, usually 2-10 times per day. If I go to youtube, it's guaranteed to crash within an hour.
It sure would be nice if it didn't crash my entire browser session every single time the current tab crashed (hint: flash. Hint2: Flash.)
I would *@#$@*# kill for a browser that didn't suck quite as horrifically as firefox.
If you honestly can't tell that the Democrats are a classically conservative party on almost all issues (leaning more to the moderate side) and somehow manage to think of them as socialist, then you shouldn't vote.
I shudder to think what would happen if there was an actual socialist party in the USA (which actually ran for office, not the hobby ones). Would half the country's heads asplode? Would Fox News implode, leaving a black hole on millions of televisions simultaneously sucking in all light and sound? Would the world as we know it end in an instant?
Special clown hint: If someone managed to trace your secret clown activities back to the random open wifi LAN you connect to, then compares that with their secret spook records of every MAC address in every wifi card ever sold, they won't find a match.
Also, when they just randomly detain ten thousand people and search everyone's laptop without a warrant trying to find a match (like say at the border crossing on your way to the clown convention), the MAC address in your laptop won't be traceable to what you did last Tuesday. Of course, you'd better hope you have some good stego in that box... and a secret compartment for your clown shoes.
I mean, think about it, if the signal takes 30,000 years to reach it's destination, not only would everyone who was alive when you sent the signal be dead, but roughly 1000 generations would have lived and died. Governments, societies, religions would likely have all come and gone, risen and fallen. Or, these being people with such staggeringly awesome technological prowess that they can travel between the stars, they individually live for vast periods, and over the ages have built more stable institutions. 30,000 years might still seem a long time for cross-galactic communications, but for such people, 50 or 100 years may not matter much at all. And from one side of the galaxy to the other, each step of the way to your neighbors might only be a few years.
From Earth to Alpha Centauri is, by this measure, at least as close as England was to China during the days of the silk road.
Sadly, the ability of the OS to make use of video card memory is restricted in many ways. Generally, you can bet that anything on the video card probably needs to be mirrored in main memory, too.
For example, have a desktop background? The X server / GNOME background gizmo will need to have an uncompressed bitmap copy of it in system memory, so that they can composite it into the framebuffer on the card. Have textures for use in the 3d graphics system? You give the graphics card a copy of those when it needs them -- you keep the original in system memory. If you use the 3d engine to composite your background, then you probably have three copies - the bitmap in system memory, a copy in the card's texture memory, and the framebuffer.
And so forth. That 256MB graphics card doesn't add 256MB to your computer's memory - instead, it should be thought of as a 256MB scratch space for graphics rendering (and 95% of that ram is probably unused most of the time).
Of course, there are a lot of things that could be done to keep memory usage down, but often aren't. For example, if you were careful, you could probably hold a background image compressed in system memory, and uncompress it on the fly when it's needed. Or, if it was small, you could keep it in native-size in system memory, and use the graphics card to scale it. But the fact remains that big displays with colorful graphics use a ton of RAM.
Keep in mind that even basic modern graphics wastes more memory than that. That background image you have on your 1600x1200 desktop? 5.4 megs. Need a few composite buffers? 5.4 megs each.
Don't have a background? Just the frame buffer to activate that graphics mode itself is 5.4 megs, regardless of what you put on it.
Just to keep things in perspective here. That Commodore 64 you had ran nicely in 64k of ram, but it also only had 320x200 graphics (160x200 in 4-color mode).:-)
On my laptop, Ubuntu 7.10 did not default to sleeping when the lid was closed. Instead, I had to go to Preferences -> Power Management, and click a button to say I want it to do that. Sleep and hibernate both "just worked" though, if you click the button.
It can't come out of sleep when you open the lid, but this is a hardware limitation. You have to press the power or escape button to wake the hardware.
Since most non-Mac users are probably not used to the whole "sleep on close, wake on open" thing, it's kind of pointless to claim it "just works" or "didn't work out of the box" because of this. If it defaulted Mac-style, people would just claim that it "doesn't work" because it sleeps when they didn't expect it.
One thing that didn't just work out of the box, though, is sleeping when you close the lid at the login screen. The sleep preference is (strangely) per-user, so it only sleeps this way when you're logged in.
On the upside, the hibernate works quite well, unlike any Macs I've used where it's strangely absent.
T-Mobile seems to be the best of a bad lot in the USA. They don't mess with people much getting their phones unlocked and so forth, and generally don't seem to exhibit the quite same level of criminal depravity you see in the rest of the phone companies.
Speaking as a software engineer, the code is monumentally more valuable than any interface document.
why?
The documentation is always wrong and/or incomplete. And in the few cases where a small part of it is complete and right, the code tends to be easier to read, and indescribably easier to debug.
This is not to say that documentation is a bad thing, but in large part it's just a sad alternative people use when they don't want to let anyone read their code.
The cases where documentation is really valuable is when it describes network interfaces and file formats, with the caveat that *all* implementations need to follow the documentation.
You can merge the changes together in some reasonable way as long as the files are edited in local spots. It works like this:
Person A and Person B both check out file Version 1. Person A modifies the first half of the file. Person B modifies the last third of the file. It comes time to merge. Typically, one of them commits their changes first. For example, Person A commits. Now the file is version 2. Now, Person B attempts to commit, and is told that their version is obsolete. They ask for an update. The update process now downloads the difference between Versions 1 and 2, and applies the delta to Person B's local copy. As long as the changes are in different parts of the file, this works fine. Now Person B can commit too.
Obviously, for this to work, both people need to edit different bits of the file. If they edited the same bits, the merge algorithm would pretty much have to throw up its hands and defer to the AI. The AI being in fact the meat puppet known as Person B. "Hey, meat puppet, this is your computer talking. Merge these files for me!"
This sort of thing can work for other sorts of files too. For example, you could have a shared image, and as long as both people modified only different little bits of it, it's ok. Or you could have a huge circuit design model, and so on. Of course, This sort of thing fails miserably is most operations involve changing everything. For example, if someone applied a gimp filter, your image-merge procedure is probably screwed. The same if someone say, reformatted an entire source file.
Of course -- but I think it's a little silly to say that it's O(1). It is, but only in the trivial and non-useful sense.
The more accurate description might be: "It's O(log(N)), but that the maximum process count is such that it compares favoriably to the old scheduler in real workloads."
Of course, I'm curious as to how well your scheduler really performs on hardware. Note that doing a bit search in software (that is, a bunch of branch instructions in L1 cache) is a lot cheaper than walking an indirection tree (likely L2 or even full cache stall each time). In general, tree approaches tend to be very pretty, but don't perform quite as well as you'd hope due to cache and branch performance... Did it work out well in reality?
For small algorithms (or even medium size ones like a scheduler), I think order analysis is generally of limited use. For example, a hash table with unknown dataset size theoretically tends to be logarithmic when you consider rehashing and so forth... But a hash table is very popular because it has low average-case constants. On the other hand, devices such as hard disks can often be modelled in terms of disk seeks, in which case order analysis can map quite well to performance.
Anyway, you're quite right that the computer machine has more states than 2^[memory] as a physical device, but in as much as it creates a digital runtime environment for software to execute on, it only provides a limited number of bits to use as state. Then again, it also has a disk drive, and a network, so the actual complexity is difficult to estimate.:-)
All algorithms on a real computer have a clear upper bound, be it 2^32 (integer limits), [memory size]/data structures (allocation limit), or ultimately 2^[memory size] (state limit).
In practice, it's fairly useful to do this for a particular real-time system, because it allows you to place numeric bounds on the running time of a component. But in that case, you're not really looking for the big-O number: you're looking for the worst case time it takes, hence, the actual runtime. O(ten quadzillion) isn't very useful in practice.
Or to put it another way, a CPU scheduler that operates using a bubble sort is also O(1), since a computer can only hold so many processes in RAM.
This kind of a silly thing to say. I mean, all terminating algorithms on a finite machine are O(1) ultimately.
For example, your 1 gig machine only has 2^(1024*1024*1024*8) states it can go through to reach an answer, not including disk IO... and as we all know, O(2^[1024*1024*1024*8]) =~ O(10^2585827972) = O(1).:-)
I appreciate that you enjoy books as well, however, the point is:
The movie industry is making a bundle off of you. And they're then using that money to directly attack you and the things you believe in.
How can you expect your "anti-DRM" views, which you are "quite vocal about" to have any effect on the video cartel when in the end, they make even more money by screwing you over? You complain... but you still pay. Over and over again. For the same thing.
If it really bothers you that the industry is forcing you to pay again and again for the same thing, then just. don't. do. it. Send your money into politics instead, and see if you can buy laws that counter the cartel's legislative arm. Complaining online while simultaneously throwing your money at the same people you're complaining about just has the end effect of paying for your own opposition.
I had to re-buy my theater system, invest in a bunch of new cabling to reproduce signal routing I already had in place that was perfectly adequate, technically speaking... man. That was one irritating evolution.
... man, you're a really good consumer! The movie industry must love you
No seriously... Why didn't you just, you know, NOT BUY the new stuff, and read a book or something instead? Books are cheaper, and have better special effects than any video game.
Slashdot Mirror
The PS2 has two vector coprocessors running at 300Mhz too, though only one of them is really useful for anything. Because of Sony's general philosophy of putting a bunch of weird specialty hardware in their machines, you can't just list CPU clock rates (as relevant as that ever is to anything).
The XBox is clearly more powerful than the PS2 (though not by as much as you suggest), but the GameCube isn't.
Where the XBox, the 360, and the Wii have the biggest advantage is that they're relatively easy to program for. Writing software for specialized vector processors is a pain.
Anonymous Coward:
XanC:
No it does not. An x+1 parity computation only requires the parity block and the block being overwritten to write the new block. You take the parity, "subtract" the old data, and "add" the new data (in fact, the "subtract" and "add" are both just XOR).
Alternatively, if you're writing a full stripe, you can just compute the parity directly. This is of course preferable to doing reads, since reads are slow. Your random write performance is suffering because you have to read and write exactly two disks in the stripe.
I don't know why this old myth comes up so often. Any decent reference will explain how parity works. Maybe if Kari Byron explained RAID parity striping, it would sink in?
Doing random reads is not slow for an SSD, so of course the random write performance with RAID 5 will be much better with SSDs.
Boot time for an OS is measured from boot loader to usable system, not from power button. This is a different measurement from boot time for a whole computer system.
Why the distinction?
Well, for example, Linux can't do anything if your BIOS sucks. It could boot in half a second, but it'll still take 90 seconds to get to the boot loader. What this means is that you use the OS time when comparing operating systems.
When comparing a Mac to an Dell computer, you compare the OS and the hardware boot time together, because Apple and Dell can actually fix that BIOS stuff if you complain enough.
So, the poster above was right to compare OSX to Ubuntu using the time from boot loader.
Broaden your vision. This is about making smaller components.
What can you do with smaller components? Well, right away, you can put more stuff in the case. Your iphonanopalmtop thing can have a foldout screen and keyboard, or a bigger battery, or it can simply be lighter. I don't know about you, but I find an iPhone a bit hefty.
Now, if you look beyond next week, smaller components let you do entirely new things. You think technology is sufficient now to put a computer in a palmtop? Whatever, dude.
I want a computer in my eyeglasses. Optically corrected screens overlaying my vision. High resolution. And I want them to weigh the same as a normal pair of glasses. Don't forget to throw in a video camera for good measure.
Can we build something like that now? Or course not. That sort of thing today is either a huge bulky piece of headgear, or it's moderately bulky and has a terrible display. We need better components: much smaller, much lower power, faster.
Don't ever say we've reached the limits of useful computer technology. Until you're plugged in directly via your visual cortex and have a robot butler who brings you waffles in the morning, we haven't even reached the limits of uses we can already imagine.
I heard on TV that an omnipotent sky monkey plans to torture us all in a volcano forever because some woman made out of a guy's rib ate a snack with a talking snake.
And that was supposed to be an education show!
Because there's no reasonable alternative yet. Konqueror crashes too, and has a lot of trouble making flash work properly. Opera doesn't work well either.
And of course, it's always a pain to have to constantly override the browser ID with whatever bullshit everyone's bozo website requires.
This is so much ado about nothing. I can count on one hand the number of times I've had a problem with Firefox that would have been solved by it being in its own process.
Funny. Firefox crashes every single day for me, usually 2-10 times per day. If I go to youtube, it's guaranteed to crash within an hour.
It sure would be nice if it didn't crash my entire browser session every single time the current tab crashed (hint: flash. Hint2: Flash.)
I would *@#$@*# kill for a browser that didn't suck quite as horrifically as firefox.
Thank you, that's for the best.
If you honestly can't tell that the Democrats are a classically conservative party on almost all issues (leaning more to the moderate side) and somehow manage to think of them as socialist, then you shouldn't vote.
I shudder to think what would happen if there was an actual socialist party in the USA (which actually ran for office, not the hobby ones). Would half the country's heads asplode? Would Fox News implode, leaving a black hole on millions of televisions simultaneously sucking in all light and sound? Would the world as we know it end in an instant?
Special clown hint: If someone managed to trace your secret clown activities back to the random open wifi LAN you connect to, then compares that with their secret spook records of every MAC address in every wifi card ever sold, they won't find a match.
Also, when they just randomly detain ten thousand people and search everyone's laptop without a warrant trying to find a match (like say at the border crossing on your way to the clown convention), the MAC address in your laptop won't be traceable to what you did last Tuesday. Of course, you'd better hope you have some good stego in that box... and a secret compartment for your clown shoes.
Yes. Nobody in Seattle has worked a day this June, and we don't plan to work again until October.
Man, it rocks to live in Seattle. It's like we're the chosen people or something.
From Earth to Alpha Centauri is, by this measure, at least as close as England was to China during the days of the silk road.
Or better yet, replace it with Tom Servo. What sort of a lunatic would have Crow do kernel development?
Sadly, the ability of the OS to make use of video card memory is restricted in many ways. Generally, you can bet that anything on the video card probably needs to be mirrored in main memory, too.
For example, have a desktop background? The X server / GNOME background gizmo will need to have an uncompressed bitmap copy of it in system memory, so that they can composite it into the framebuffer on the card. Have textures for use in the 3d graphics system? You give the graphics card a copy of those when it needs them -- you keep the original in system memory. If you use the 3d engine to composite your background, then you probably have three copies - the bitmap in system memory, a copy in the card's texture memory, and the framebuffer.
And so forth. That 256MB graphics card doesn't add 256MB to your computer's memory - instead, it should be thought of as a 256MB scratch space for graphics rendering (and 95% of that ram is probably unused most of the time).
Of course, there are a lot of things that could be done to keep memory usage down, but often aren't. For example, if you were careful, you could probably hold a background image compressed in system memory, and uncompress it on the fly when it's needed. Or, if it was small, you could keep it in native-size in system memory, and use the graphics card to scale it. But the fact remains that big displays with colorful graphics use a ton of RAM.
Keep in mind that even basic modern graphics wastes more memory than that. That background image you have on your 1600x1200 desktop? 5.4 megs. Need a few composite buffers? 5.4 megs each.
:-)
Don't have a background? Just the frame buffer to activate that graphics mode itself is 5.4 megs, regardless of what you put on it.
Just to keep things in perspective here. That Commodore 64 you had ran nicely in 64k of ram, but it also only had 320x200 graphics (160x200 in 4-color mode).
On my laptop, Ubuntu 7.10 did not default to sleeping when the lid was closed. Instead, I had to go to Preferences -> Power Management, and click a button to say I want it to do that. Sleep and hibernate both "just worked" though, if you click the button.
It can't come out of sleep when you open the lid, but this is a hardware limitation. You have to press the power or escape button to wake the hardware.
Since most non-Mac users are probably not used to the whole "sleep on close, wake on open" thing, it's kind of pointless to claim it "just works" or "didn't work out of the box" because of this. If it defaulted Mac-style, people would just claim that it "doesn't work" because it sleeps when they didn't expect it.
One thing that didn't just work out of the box, though, is sleeping when you close the lid at the login screen. The sleep preference is (strangely) per-user, so it only sleeps this way when you're logged in.
On the upside, the hibernate works quite well, unlike any Macs I've used where it's strangely absent.
T-Mobile seems to be the best of a bad lot in the USA. They don't mess with people much getting their phones unlocked and so forth, and generally don't seem to exhibit the quite same level of criminal depravity you see in the rest of the phone companies.
Speaking as a software engineer, the code is monumentally more valuable than any interface document.
why?
The documentation is always wrong and/or incomplete. And in the few cases where a small part of it is complete and right, the code tends to be easier to read, and indescribably easier to debug.
This is not to say that documentation is a bad thing, but in large part it's just a sad alternative people use when they don't want to let anyone read their code.
The cases where documentation is really valuable is when it describes network interfaces and file formats, with the caveat that *all* implementations need to follow the documentation.
("The Atrocity Archives", and "The Jennifer Morgue")
You can merge the changes together in some reasonable way as long as the files are edited in local spots. It works like this:
Person A and Person B both check out file Version 1.
Person A modifies the first half of the file.
Person B modifies the last third of the file.
It comes time to merge. Typically, one of them commits their changes first. For example, Person A commits. Now the file is version 2.
Now, Person B attempts to commit, and is told that their version is obsolete. They ask for an update.
The update process now downloads the difference between Versions 1 and 2, and applies the delta to Person B's local copy. As long as the changes are in different parts of the file, this works fine.
Now Person B can commit too.
Obviously, for this to work, both people need to edit different bits of the file. If they edited the same bits, the merge algorithm would pretty much have to throw up its hands and defer to the AI. The AI being in fact the meat puppet known as Person B. "Hey, meat puppet, this is your computer talking. Merge these files for me!"
This sort of thing can work for other sorts of files too. For example, you could have a shared image, and as long as both people modified only different little bits of it, it's ok. Or you could have a huge circuit design model, and so on. Of course, This sort of thing fails miserably is most operations involve changing everything. For example, if someone applied a gimp filter, your image-merge procedure is probably screwed. The same if someone say, reformatted an entire source file.
Your test is invalid. Try again with 10000 different files, and make sure you unmount/mount before each test.
Of course -- but I think it's a little silly to say that it's O(1). It is, but only in the trivial and non-useful sense.
:-)
The more accurate description might be: "It's O(log(N)), but that the maximum process count is such that it compares favoriably to the old scheduler in real workloads."
Of course, I'm curious as to how well your scheduler really performs on hardware. Note that doing a bit search in software (that is, a bunch of branch instructions in L1 cache) is a lot cheaper than walking an indirection tree (likely L2 or even full cache stall each time). In general, tree approaches tend to be very pretty, but don't perform quite as well as you'd hope due to cache and branch performance... Did it work out well in reality?
For small algorithms (or even medium size ones like a scheduler), I think order analysis is generally of limited use. For example, a hash table with unknown dataset size theoretically tends to be logarithmic when you consider rehashing and so forth... But a hash table is very popular because it has low average-case constants. On the other hand, devices such as hard disks can often be modelled in terms of disk seeks, in which case order analysis can map quite well to performance.
Anyway, you're quite right that the computer machine has more states than 2^[memory] as a physical device, but in as much as it creates a digital runtime environment for software to execute on, it only provides a limited number of bits to use as state. Then again, it also has a disk drive, and a network, so the actual complexity is difficult to estimate.
This is true, but again, kind of silly.
All algorithms on a real computer have a clear upper bound, be it 2^32 (integer limits), [memory size]/data structures (allocation limit), or ultimately 2^[memory size] (state limit).
In practice, it's fairly useful to do this for a particular real-time system, because it allows you to place numeric bounds on the running time of a component. But in that case, you're not really looking for the big-O number: you're looking for the worst case time it takes, hence, the actual runtime. O(ten quadzillion) isn't very useful in practice.
Or to put it another way, a CPU scheduler that operates using a bubble sort is also O(1), since a computer can only hold so many processes in RAM.
Ingo,
:-)
This kind of a silly thing to say. I mean, all terminating algorithms on a finite machine are O(1) ultimately.
For example, your 1 gig machine only has 2^(1024*1024*1024*8) states it can go through to reach an answer, not including disk IO... and as we all know, O(2^[1024*1024*1024*8]) =~ O(10^2585827972) = O(1).
(Sorry for the late reply)
I appreciate that you enjoy books as well, however, the point is:
The movie industry is making a bundle off of you. And they're then using that money to directly attack you and the things you believe in.
How can you expect your "anti-DRM" views, which you are "quite vocal about" to have any effect on the video cartel when in the end, they make even more money by screwing you over? You complain... but you still pay. Over and over again. For the same thing.
If it really bothers you that the industry is forcing you to pay again and again for the same thing, then just. don't. do. it. Send your money into politics instead, and see if you can buy laws that counter the cartel's legislative arm. Complaining online while simultaneously throwing your money at the same people you're complaining about just has the end effect of paying for your own opposition.
No seriously... Why didn't you just, you know, NOT BUY the new stuff, and read a book or something instead? Books are cheaper, and have better special effects than any video game.