How do you expect a 32-bit program with no knowledge of 64-bit processors to be able to tell the OS to not give it the full 4 GB, because the developer wasn't careful?
That happens by default on Windows. By default, programs only get 2GB of address space, and Windows "uses" (just doesn't give out, really) the other 2GB.
If a programmer thinks they're careful, they opt into the larger address space by setting the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in their PE header (usually by passing a linker flag).
So now we can get to your question, and there are two answers:
1) Even if a program doesn't have knowledge of 64-bit Windows, they can still get some benefit from setting that flag: on a 32-bit Windows system configured to support it, they'll get a 3GB address space instead of 2GB.
2) If a program has no knowledge about the large-address-aware flag at all, then they "tell the OS to not give it the full 4 GB" by doing nothing.
In Firefox's case, Mozilla has set this flag:
C:\Program Files (x86)\Mozilla Firefox>dumpbin/headers firefox.exe ... FILE HEADER VALUES
14C machine (x86) ...
122 characteristics
Executable
Application can handle large (>2GB) addresses <--
32 bit word machine ...
(You could probably actually modify the Firefox executable to unset that flag and stop it from using above 2GB of user memory, but I'm not sure what would happen or if there are other mechanisms that can overrule it or whatever.)
The direction in which I take this line of discussion depends on what fraction of the total audience a particular game needs before it's considered successful.
Also, I don't really care what the answer to this question is. I'm not looking at things from the point of view of the game developer and trying to argue that it makes sense for publishers to include DRM or not include DRM or whatever; I'm looking at things from the point of view of the gamer, who has to decide between supporting DRM-ed products or going without games they probably want.
Or do you claim that someone is likely to browse through GOG and see absolutely no worthwhile games?
Absolutely not.
What I mean is the following: if you were to ask everyone who plays PC games (maybe exclude the guy who just dabbles in solitaire in his spare time) what their favorites are and what games they haven't played that they would most like to, I strongly suspect that almost all of those lists will have games that are only available with DRM.
It doesn't have to be the same game between different people: maybe I put Portal on my list, you put HL2 on your list, someone else puts Mass Effect on their list. But there will be very few lists consisting entirely of games available DRM-free.
Sticking to DRM-free games will cause you to miss out on a ton of good stuff. If it's a strong principle to avoid DRM then it's worth it, but for most people that's not the case.
But here's the thing; in some sense, I don't really view it as as ethical or moral issue. (Of course, it becomes such if it isn't disclosed.) To me, it's just another angle on the business transaction of purchasing the game. I understand people who do view it that way, but I am not one of them and nor are most people I suspect.
I mean, take one of the things that people say about DRM: that it's "defective by design." Let's assume that I agree with that. Well, here's the thing -- it's quite reasonable to knowingly buy defective stuff! There are outlet stores and whatnot where they have racks of clothes for instance where there's something wrong, and they are sold at a discount. If I can get something that, practically speaking, works pretty well as a shirt and doesn't look too bad, why wouldn't buy it? Sure, I'm not going to pay full price, but I'm not going to leave it on the rack out of principle. Same with games; maybe I'd be willing to have paid $60 for Mass Effect 3 without DRM, but since it's on the defective rack, I waited until I could get it for $30. If it was on some "really defective, you have to be online to wear this" rack, maybe it'd have dropped to $5 or $10.
The only ethical concern to me is the slippery slope: if you can't get DRM-free programs at all, and stuff like that. But that's not now. (Actually the "they're games" argument works in favor of my position, because there's a much less compelling argument re. vendor lockin. If Valve cuts off access to Portal or something I'll be pissed, but it's not like my livelihood will be threatened or I'll be unable to access years' of work.)
He is that stupid. And so are most people. Every compu-geek is saying, geee why didn't they use P-geeee-pee or Gee-Pee-Gee or one-time-pads, or steganography in images of zebras!!! And people here think that they're a lot smarter than they really are, or probably are
I believe The Onion had an interesting investigative report on the topic of that observation applied to national security.
Download isn't physical media and is inferior in many situations and fatal in some. Flash would definitely have been an alternative, but is substantially more expensive and doesn't retain compatibility with people's existing audio CDs, DVDs, and movie blu-ray discs.
Besides, I wouldn't be too surprised if there would be a way for game devs to distribute games on flash (especially if they start bugging MS for it), and I'd be astonished if there's no game download service. I mean, that already exists; it's not like DVDs are the only way to get games onto a 360. Just because MS says "hey we've got a blu-ray drive" doesn't mean that's what every single game will use.
And why does it have to be 1080p? Lower resolutions don't exist?
They exist, but given the choice between "stream a lower resolution" and "wait a couple days for a blu-ray at 1080p", for many things and in most situations, I at least would choose the latter.
But the vast majority of PC games on GOG or Humble Bundle are DRM-free, as are open-source games downloaded from the developer's own web site.
And what percentage of PC games that most people would want to play are available on GOG, a Humble Bundle, or as an open-source game on the developer's web site?
Many of the best games out there (including my favorite, Portal, and many of my other top games) are not available in any of those sources. I am happy that DRM-free indie games seem to be gaining popularity, but there's still a long way to go. Even some great indie games, like Mark of the Ninja (I think), are only available on Steam.
Just to clarify, I'm talking about the data cache. The shared I-cache is another factor that blurs the distinction and moves it closer to the SMT end of the spectrum, but still not past the halfway point IMO.
That basically leaves the shared decoder and dispatcher
Eh, yes and no. So with the disclaimer that I'm no architect, here's my viewpoint:
From the block diagram I saw, the halves of a module have separate integer pipes and separate L1 caches. IMO, if you say that I'm allowed to have a spectrum between "independent cores" and "SMT", those two characteristics on their own put Bulldozer at least halfway between the endpoints, and if I'm forced to pick a side I'm going to go with "two cores" rather than "one core SMT".
Put it this way. The shared FPU doesn't kill the fact that they're separate cores. Is the Sun Niagra an 8-core chip (each core 4-way SMT) with a single shared FPU, or is it a 32-way SMT single-core chip with a single shared FPU? Because I suspect basically everyone would agree that the former is a far more accurate description than the latter.
That basically leaves the shared decoder and dispatcher. And in my mind, the separate L1 caches "separate" the two halves at least as much as the decoder & dispatcher bind them together.
So while it is probably misleading and incorrect to call bulldozer an 8-core chip, I feel it's more misleading to call bulldozer a 4-core, 2-way SMT chip.
You'll still close off way way more than most people are willing to.
For instance, my favorite video game, without a doubt, is Portal. But that's on Steam, which is DRM. Granted, it's not always-online or limited-install crap, but DRM it most definitely is.
If you're OK getting something like Portal, than you've... well, your anti-DRM ideas have their price in some sense. (I'm not trying to criticize here -- mine definitely have their own price -- but just be realistic.) And at that point it's the old joke about how now it's just a matter of haggling over price, as you've established that your attitude is "DRM decreases the value of something" instead of "I won't buy DRM at all." And at that point, who's to say that the console price isn't below the limit?
If you're not OK even with Steam, I legitimately applaud you sticking to your ideals. But at the same time -- most people, like me, are not in that camp. Sure, there are some good games that are available DRM free (most notably, some old games and some of the things in the Humble Bundles like Psychonauts and Braid), but you're still missing out on a ton.
As for the Nook â" why not an Amazon Kindle (arguably a better selection) or a full fledge table (better everything, but higher cost)?
Tablets are worse for reading, IMO; I'm much more of a fan of the Kindle-style e-ink. I haven't tried an iPad Mini, but I suspect they're also heavier.
have you considered to use apt-get --download-only and then use dpkg --instdir.
I mean download the packages and then install with specifying the install directory?
Aside from the fact that we're on an RPM-based distribution, dpkg requires root and it doesn't allow a program and dependent library to be installed to two different instrdirs, as when running the installation scripts it chroots to the instdir. So if I put the library in/net/library, and try to install the program with --instdir=/net/program, then my reading of the man page says that it won't be able to see/net/library.
If libfoo is done correctly, any program linked with version 1.0.0 should Just Work with version 1.0.1239
Here's the problem: the Linux ecosystem has a much more liberal interpretation of "Just Work" than MS does. MS's approach I think is quite a bit closer to "any change is a potentially-breaking change" which is why they keep around a lot of minor updates which on Linux would just replace the old file. It gets to this point:
Yes, that's the question of the extent to which the real "specification" upon which clients depend on is the official specification or the full behavior of the implementation, and the extent to which you're willing to tell developers of code that doesn't fit the former specification but fits the latter specification to go pound sand if you "break" their code
I don't actually know why the situation seems to be a lot different on the two systems. Maybe Linux changes really do break software fairly frequently, and it's just rarely-used software that few care about and the Linux people are fully prepared to say "oh well, deal with it" in situations where MS would maintain compatibility. Maybe the fact that most Linux software has source available means that the problem is reduced a bit, because a recompile will sometimes fix the problem. Maybe the design of Unix better encourages people to write software which depends only on the documented specification instead of implementation details. I really have no clue.
Fine, I'll give you a real-world scenario as best as I can. In a moment, I'll switch over to my Windows box and compile something on SSD and then on HDD. We'll see who wins.
OK. So the difference was actually very small, only 1-2%, though it did hold up across several runs and configurations. I also tried HL2 level loading times, and saw about a 4% improvement there.
In all cases I explicitly warmed the cache. And for the compiler scenario especially, that's a very realistic scenario. (Though I'd be very interested in trying it on my work computer, which has far more cores -- that would put more stress on the I/O system. Too bad I don't have an SSD in that machine.)
However, I still am going to stand by my statement that an SSD will often help, because I'm not convinced that having the cache warmed is the common scenario, or would be the common scenario even if you got a very large amount of RAM. (This is also in response to part of one of your comments that I didn't address earlier, where you mentioned preloading again.)
Take that 24GB number. In a typical month, I will (1) play multiple large games, often which I haven't played for a while (e.g. I go back to Portal 2 every few weeks and play some more PTI levels), use a couple programs like Latex with an absolute ton of tiny files (an enormous hit if they are not in cache), open up my photo library in lightroom (where just the catalog of previews is over 6 GB and I can easily hit ten gigs of photos just by flipping through things), and often record a video with Fraps (~2 GB/minute) and then do some light video editing. Now, I can't put all of that onto an SSD. But I can come a hell of a lot closer then getting it into RAM.
The problem with caches in general is that they can only react. If what you do changes around between different data-intensive tasks fairly rapidly and your cache isn't big enough, there's only so much it can do. If in my real usage the level load times dropped -- and they definitely have -- that's what matters.
" offers 256 MB of Samsung DDR2 SDRAM cache memory", just to re-iterate, SSD makers add RAM cache because RAM cache is faster.
That speed is after the RAM cache is through.
Don't believe me? Another benchmark. That's a random drive that I arrived at by entering "anandtech ssd review" into Google and picking the first link. It's not even the fastest drive in the charts on that page, by far.
The write speed they measured was 317 MB/s. The total amount of data written to the disk was over 100 GB -- so plenty to get past the RAM cache and to the actual SSD. If the 317 MB/s is limited by the RAM and not Flash speed, that means the Flash is even faster.
Don't like that benchmark or Anandtech? OK, here's one from Tom's Hardware. Measured the time do decompress a 50 GB folder. (Again, the RAM cache on the drive and your OS buffer cache (<8GB) isn't gonna save you.) The throughput during that test was ~300 MB/s. You can't get that if you're not writing that fast to the flash.
and benchmark scenarios that don't happen in the real world.
Fine, I'll give you a real-world scenario as best as I can. In a moment, I'll switch over to my Windows box and compile something on SSD and then on HDD. We'll see who wins.
" offers 256 MB of Samsung DDR2 SDRAM cache memory", just to re-iterate, SSD makers add RAM cache because RAM cache is faster.
That speed is after the RAM cache is through.
Don't believe me? Another benchmark. That's a random drive that I arrived at by entering "anandtech ssd review" into Google and picking the first link. It's not even the fastest drive in the charts on that page, by far.
The write speed they measured was 317 MB/s. The total amount of data written to the disk was over 100 GB -- so plenty to get past the RAM cache and to the actual SSD. If the 317 MB/s is limited by the RAM and not Flash speed, that means the Flash is even faster.
Don't like that benchmark or Anandtech? OK, here's one from Tom's Hardware. Measured the time do decompress a 50 GB folder. (Again, the RAM cache on the drive and your OS buffer cache (and benchmark scenarios that don't happen in the real world.
Fine, I'll give you a real-world scenario as best as I can. In a moment, I'll switch over to my Windows box and compile something on SSD and then on HDD. We'll see who wins.
And as I discuss a little bit in a reply to your sibling, from the manpage it sounds like it wouldn't work.
The --root doc says "Changing root changes instdir to dir and admindir to dir/var/lib/dpkg", and the --instdir doc says that option causes it to chroot to that directory to run the installation scripts. (Also the fact that it chroots means it needs root.) But that's no good if packages aren't completely self-contained. If I want to install a program into/opt/program and a library it uses into/opt/library, there's no directory to give the program such that it will install correctly and still be able to see the library.
I suppose that it might work if you do make a self-contained package, but it's still not an out-of-the-box solution.
So HL2 requires 4.5GB of disk, to need all of it, you'd have to play the game completely through in a fixed order (based on the order of files on the disk if that's even possible), then you need to find 9 other games, that don't share files in common with HL2 and play those all the way through... and... then if you did that, you'd gain the seek time (50ms?) of a hard disk on the next game load.
And by the way, you're continually ignoring my statement that the SSD cache persists across boots. With an SSD cache, playing HL2 today helps it go fast tomorrow. With a buffer cache, it does not.
That's not what's on offer here, you don't get to decide HL2 should be in SSD, the caching algo decides which files in HL2 are cached based on how frequently you use it.
Yes, I know. I'm relying on extrapolating from anandtech's statement that game loading speeds are helped a great deal.
Likewise Windows caching algo decides the same for RAM. In WD's case, it works with that Windows caching algo, so they're one and the same algo.
So the WD's algorithm is perhaps not as good as Intel's Smart Response. Benchmarks would tell. That doesn't torpedo the idea of an SSD or hybrid drive, however.
Specifically you'd have to cycle through data heavy games that use MORE than 48GB in total (to ensure the 24GB of ram equivalent would be completely flushed)
That's unlikely. Typical buffer cache replacement algorithms are approximating LRU. If it were perfect LRU, then cycling 24GB of data plus 1 page would be sufficient. Since it's only approximate it would be rather less, but there are also "inefficiencies" in that figure that would raise it. In any case, you would be highly unlikely to require anything remotely close to 48 GB.
AND don't share common files, so for example the games don't reuse DX and drivers because they'd be in cache and would break up your long reads algo
You think it's DX drivers that cause game load times to be long?! No, it's level data and textures and models and such.
Flash is very slow to write
Write speed for HDD: "The range can be anywhere from 50 â" 120MB / s" Write speed for SSD: "Generally above 200 MB/s and up to 500 MB/s for cutting edge drives" source
Presumably WD stick some RAM on there too to cache the writes to flash.
No, they don't. They use better flash and they bank them.
Take your pick of either of the following responses; I'm feeling a bit sarcastic at the moment. ---- Oh, I didn't realize that Linux was better than Windows on embedded systems.
[After all, from what you said before, one might as well use Windows if you're on a system where resource usage isn't at the top of the list.] --- Ah yes. I forgot. Everyone is forced to use the same distribution and same software. That's really too bad... a solution which was more inefficient in terms of resource use but had some properties which would make desktop use nicer would have been nice. But alas.
Slashdot Mirror
That happens by default on Windows. By default, programs only get 2GB of address space, and Windows "uses" (just doesn't give out, really) the other 2GB.
If a programmer thinks they're careful, they opt into the larger address space by setting the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in their PE header (usually by passing a linker flag).
So now we can get to your question, and there are two answers:
1) Even if a program doesn't have knowledge of 64-bit Windows, they can still get some benefit from setting that flag: on a 32-bit Windows system configured to support it, they'll get a 3GB address space instead of 2GB.
2) If a program has no knowledge about the large-address-aware flag at all, then they "tell the OS to not give it the full 4 GB" by doing nothing.
In Firefox's case, Mozilla has set this flag:
(You could probably actually modify the Firefox executable to unset that flag and stop it from using above 2GB of user memory, but I'm not sure what would happen or if there are other mechanisms that can overrule it or whatever.)
The direction in which I take this line of discussion depends on what fraction of the total audience a particular game needs before it's considered successful.
Also, I don't really care what the answer to this question is. I'm not looking at things from the point of view of the game developer and trying to argue that it makes sense for publishers to include DRM or not include DRM or whatever; I'm looking at things from the point of view of the gamer, who has to decide between supporting DRM-ed products or going without games they probably want.
Or do you claim that someone is likely to browse through GOG and see absolutely no worthwhile games?
Absolutely not.
What I mean is the following: if you were to ask everyone who plays PC games (maybe exclude the guy who just dabbles in solitaire in his spare time) what their favorites are and what games they haven't played that they would most like to, I strongly suspect that almost all of those lists will have games that are only available with DRM.
It doesn't have to be the same game between different people: maybe I put Portal on my list, you put HL2 on your list, someone else puts Mass Effect on their list. But there will be very few lists consisting entirely of games available DRM-free.
Sticking to DRM-free games will cause you to miss out on a ton of good stuff. If it's a strong principle to avoid DRM then it's worth it, but for most people that's not the case.
But here's the thing; in some sense, I don't really view it as as ethical or moral issue. (Of course, it becomes such if it isn't disclosed.) To me, it's just another angle on the business transaction of purchasing the game. I understand people who do view it that way, but I am not one of them and nor are most people I suspect.
I mean, take one of the things that people say about DRM: that it's "defective by design." Let's assume that I agree with that. Well, here's the thing -- it's quite reasonable to knowingly buy defective stuff! There are outlet stores and whatnot where they have racks of clothes for instance where there's something wrong, and they are sold at a discount. If I can get something that, practically speaking, works pretty well as a shirt and doesn't look too bad, why wouldn't buy it? Sure, I'm not going to pay full price, but I'm not going to leave it on the rack out of principle. Same with games; maybe I'd be willing to have paid $60 for Mass Effect 3 without DRM, but since it's on the defective rack, I waited until I could get it for $30. If it was on some "really defective, you have to be online to wear this" rack, maybe it'd have dropped to $5 or $10.
The only ethical concern to me is the slippery slope: if you can't get DRM-free programs at all, and stuff like that. But that's not now. (Actually the "they're games" argument works in favor of my position, because there's a much less compelling argument re. vendor lockin. If Valve cuts off access to Portal or something I'll be pissed, but it's not like my livelihood will be threatened or I'll be unable to access years' of work.)
I believe The Onion had an interesting investigative report on the topic of that observation applied to national security.
Oooo, or the Xbox Continuum. That actually even sounds kind of markety.
Although, what would you have called its successor... Xbox Infinity-Plus-One?
The Xbox Aleph-1.
Download isn't physical media and is inferior in many situations and fatal in some. Flash would definitely have been an alternative, but is substantially more expensive and doesn't retain compatibility with people's existing audio CDs, DVDs, and movie blu-ray discs.
Besides, I wouldn't be too surprised if there would be a way for game devs to distribute games on flash (especially if they start bugging MS for it), and I'd be astonished if there's no game download service. I mean, that already exists; it's not like DVDs are the only way to get games onto a 360. Just because MS says "hey we've got a blu-ray drive" doesn't mean that's what every single game will use.
And why does it have to be 1080p? Lower resolutions don't exist?
They exist, but given the choice between "stream a lower resolution" and "wait a couple days for a blu-ray at 1080p", for many things and in most situations, I at least would choose the latter.
Or you bought a DRM'd thing during an irrational lapse of judgement.
If "you're OK getting something like Portal", either it wasn't a lapse of judgement or said lapse is continuing.
But the vast majority of PC games on GOG or Humble Bundle are DRM-free, as are open-source games downloaded from the developer's own web site.
And what percentage of PC games that most people would want to play are available on GOG, a Humble Bundle, or as an open-source game on the developer's web site?
Many of the best games out there (including my favorite, Portal, and many of my other top games) are not available in any of those sources. I am happy that DRM-free indie games seem to be gaining popularity, but there's still a long way to go. Even some great indie games, like Mark of the Ninja (I think), are only available on Steam.
...separate L1 caches...
Just to clarify, I'm talking about the data cache. The shared I-cache is another factor that blurs the distinction and moves it closer to the SMT end of the spectrum, but still not past the halfway point IMO.
That basically leaves the shared decoder and dispatcher
I guess also the bus interface from the module.
Eh, yes and no. So with the disclaimer that I'm no architect, here's my viewpoint:
From the block diagram I saw, the halves of a module have separate integer pipes and separate L1 caches. IMO, if you say that I'm allowed to have a spectrum between "independent cores" and "SMT", those two characteristics on their own put Bulldozer at least halfway between the endpoints, and if I'm forced to pick a side I'm going to go with "two cores" rather than "one core SMT".
Put it this way. The shared FPU doesn't kill the fact that they're separate cores. Is the Sun Niagra an 8-core chip (each core 4-way SMT) with a single shared FPU, or is it a 32-way SMT single-core chip with a single shared FPU? Because I suspect basically everyone would agree that the former is a far more accurate description than the latter.
That basically leaves the shared decoder and dispatcher. And in my mind, the separate L1 caches "separate" the two halves at least as much as the decoder & dispatcher bind them together.
So while it is probably misleading and incorrect to call bulldozer an 8-core chip, I feel it's more misleading to call bulldozer a 4-core, 2-way SMT chip.
Buy a PC and don't buy DRM-infested garbage.
You'll still close off way way more than most people are willing to.
For instance, my favorite video game, without a doubt, is Portal. But that's on Steam, which is DRM. Granted, it's not always-online or limited-install crap, but DRM it most definitely is.
If you're OK getting something like Portal, than you've... well, your anti-DRM ideas have their price in some sense. (I'm not trying to criticize here -- mine definitely have their own price -- but just be realistic.) And at that point it's the old joke about how now it's just a matter of haggling over price, as you've established that your attitude is "DRM decreases the value of something" instead of "I won't buy DRM at all." And at that point, who's to say that the console price isn't below the limit?
If you're not OK even with Steam, I legitimately applaud you sticking to your ideals. But at the same time -- most people, like me, are not in that camp. Sure, there are some good games that are available DRM free (most notably, some old games and some of the things in the Humble Bundles like Psychonauts and Braid), but you're still missing out on a ton.
As for the Nook â" why not an Amazon Kindle (arguably a better selection) or a full fledge table (better everything, but higher cost)?
Tablets are worse for reading, IMO; I'm much more of a fan of the Kindle-style e-ink. I haven't tried an iPad Mini, but I suspect they're also heavier.
Aside from the fact that we're on an RPM-based distribution, dpkg requires root and it doesn't allow a program and dependent library to be installed to two different instrdirs, as when running the installation scripts it chroots to the instdir. So if I put the library in /net/library, and try to install the program with --instdir=/net/program, then my reading of the man page says that it won't be able to see /net/library.
So no, it wouldn't work.
Here's the problem: the Linux ecosystem has a much more liberal interpretation of "Just Work" than MS does. MS's approach I think is quite a bit closer to "any change is a potentially-breaking change" which is why they keep around a lot of minor updates which on Linux would just replace the old file. It gets to this point:
I don't actually know why the situation seems to be a lot different on the two systems. Maybe Linux changes really do break software fairly frequently, and it's just rarely-used software that few care about and the Linux people are fully prepared to say "oh well, deal with it" in situations where MS would maintain compatibility. Maybe the fact that most Linux software has source available means that the problem is reduced a bit, because a recompile will sometimes fix the problem. Maybe the design of Unix better encourages people to write software which depends only on the documented specification instead of implementation details. I really have no clue.
OK. So the difference was actually very small, only 1-2%, though it did hold up across several runs and configurations. I also tried HL2 level loading times, and saw about a 4% improvement there.
In all cases I explicitly warmed the cache. And for the compiler scenario especially, that's a very realistic scenario. (Though I'd be very interested in trying it on my work computer, which has far more cores -- that would put more stress on the I/O system. Too bad I don't have an SSD in that machine.)
However, I still am going to stand by my statement that an SSD will often help, because I'm not convinced that having the cache warmed is the common scenario, or would be the common scenario even if you got a very large amount of RAM. (This is also in response to part of one of your comments that I didn't address earlier, where you mentioned preloading again.)
Take that 24GB number. In a typical month, I will (1) play multiple large games, often which I haven't played for a while (e.g. I go back to Portal 2 every few weeks and play some more PTI levels), use a couple programs like Latex with an absolute ton of tiny files (an enormous hit if they are not in cache), open up my photo library in lightroom (where just the catalog of previews is over 6 GB and I can easily hit ten gigs of photos just by flipping through things), and often record a video with Fraps (~2 GB/minute) and then do some light video editing. Now, I can't put all of that onto an SSD. But I can come a hell of a lot closer then getting it into RAM.
The problem with caches in general is that they can only react. If what you do changes around between different data-intensive tasks fairly rapidly and your cache isn't big enough, there's only so much it can do. If in my real usage the level load times dropped -- and they definitely have -- that's what matters.
Bungled my HTML. Here we go again:
That speed is after the RAM cache is through.
Don't believe me? Another benchmark. That's a random drive that I arrived at by entering "anandtech ssd review" into Google and picking the first link. It's not even the fastest drive in the charts on that page, by far.
The write speed they measured was 317 MB/s. The total amount of data written to the disk was over 100 GB -- so plenty to get past the RAM cache and to the actual SSD. If the 317 MB/s is limited by the RAM and not Flash speed, that means the Flash is even faster.
Don't like that benchmark or Anandtech? OK, here's one from Tom's Hardware. Measured the time do decompress a 50 GB folder. (Again, the RAM cache on the drive and your OS buffer cache (<8GB) isn't gonna save you.) The throughput during that test was ~300 MB/s. You can't get that if you're not writing that fast to the flash.
Fine, I'll give you a real-world scenario as best as I can. In a moment, I'll switch over to my Windows box and compile something on SSD and then on HDD. We'll see who wins.
That speed is after the RAM cache is through.
Don't believe me? Another benchmark. That's a random drive that I arrived at by entering "anandtech ssd review" into Google and picking the first link. It's not even the fastest drive in the charts on that page, by far.
The write speed they measured was 317 MB/s. The total amount of data written to the disk was over 100 GB -- so plenty to get past the RAM cache and to the actual SSD. If the 317 MB/s is limited by the RAM and not Flash speed, that means the Flash is even faster.
Don't like that benchmark or Anandtech? OK, here's one from Tom's Hardware. Measured the time do decompress a 50 GB folder. (Again, the RAM cache on the drive and your OS buffer cache (and benchmark scenarios that don't happen in the real world.
Fine, I'll give you a real-world scenario as best as I can. In a moment, I'll switch over to my Windows box and compile something on SSD and then on HDD. We'll see who wins.
And as I discuss a little bit in a reply to your sibling, from the manpage it sounds like it wouldn't work.
The --root doc says "Changing root changes instdir to dir and admindir to dir/var/lib/dpkg", and the --instdir doc says that option causes it to chroot to that directory to run the installation scripts. (Also the fact that it chroots means it needs root.) But that's no good if packages aren't completely self-contained. If I want to install a program into /opt/program and a library it uses into /opt/library, there's no directory to give the program such that it will install correctly and still be able to see the library.
I suppose that it might work if you do make a self-contained package, but it's still not an out-of-the-box solution.
Pointers to documentation? Does it require root?
And by the way, you're continually ignoring my statement that the SSD cache persists across boots. With an SSD cache, playing HL2 today helps it go fast tomorrow. With a buffer cache, it does not.
Yes, I know. I'm relying on extrapolating from anandtech's statement that game loading speeds are helped a great deal.
So the WD's algorithm is perhaps not as good as Intel's Smart Response. Benchmarks would tell. That doesn't torpedo the idea of an SSD or hybrid drive, however.
That's unlikely. Typical buffer cache replacement algorithms are approximating LRU. If it were perfect LRU, then cycling 24GB of data plus 1 page would be sufficient. Since it's only approximate it would be rather less, but there are also "inefficiencies" in that figure that would raise it. In any case, you would be highly unlikely to require anything remotely close to 48 GB.
You think it's DX drivers that cause game load times to be long?! No, it's level data and textures and models and such.
Write speed for HDD: "The range can be anywhere from 50 â" 120MB / s"
Write speed for SSD: "Generally above 200 MB/s and up to 500 MB/s for cutting edge drives"
source
No, they don't. They use better flash and they bank them.
Take your pick of either of the following responses; I'm feeling a bit sarcastic at the moment.
----
Oh, I didn't realize that Linux was better than Windows on embedded systems.
[After all, from what you said before, one might as well use Windows if you're on a system where resource usage isn't at the top of the list.]
---
Ah yes. I forgot. Everyone is forced to use the same distribution and same software. That's really too bad... a solution which was more inefficient in terms of resource use but had some properties which would make desktop use nicer would have been nice. But alas.