QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: doppler on October 12, 2021, 08:28:29 am
-
Anybody with a brain knows SSD's are nice and fast readers. But have a limited write life. After so many writes it just won't write anymore. So to get more life out of it things have to be in other places. Things needing a new location (on a spinning HDD), are pagefile, swapfile, windows temp location, general temp location and any program that uses installed location to put temp stuff. I won't go into; it there are ton's of articles explaining it all.
-----> I plan to install QB64 on the spinning disk one. The question becomes is there a temp location created that QB64 may use during compile or creation that is not under the QB64 directory location? Remember the environment temps will be also moved.
BTW, if after reading my first paragraph you still think you don't have to do any of the things mentioned. It's in your best interest to read about write life of SSD's. I am unhappy enough I won't be able to de-fragment large files anymore. ie: seek times of HDD made that a plus. SSD's have no seek time.
-
If its a dual drive system, I'd put it on the normal drive. QB64 is notorious for reading a writing your whole program to disk with *each and every* keypress. This insane use of writing, rewriting, overwriting, and writing some more, isn't all that good for a SSD.
IF the system just has a SSD, but has sufficient memory, then I'd allocate 2GB or so to a persistent RAMdrive, copy QB64 to there, and run it fully out of RAM.
If neither choice is viable, you just do whatcha got to do and live with it. :P
-
It's not just a single SSD involved. It will come with a standard HDD (secondary) and I plan to add two more "Large HDD's" as well. Poor programming apps are known to use other locations. Be it on a drive or the registry. I have not seen anyway to move the registry to another drive. So all the registry write will be SSD writes.
-
Then just put QB64 on your secondary HDD and you'll be golden. 👌
-
I've got QB64 on my SSD right now. You'd have to do a whole lot of writing, even with QB64, to wear out your SSD. I might move mine to a HDD when I get my new PC, just because I won't need a super quick access to QB64
-
I've got QB64 on my SSD right now. You'd have to do a whole lot of writing...
That's the fallacy of SSD's. People think it's not a problem because of the millions of write cycles. I plan to use my computers at least for 8 years. At the end-of-life, it's so outdated it's not funny. Left unchanged you would be lucky to get three years out of a SSD. Heavy user even less time. The windows O/S is a known talker, be it the ethernet, monitor, speakers, usb's and HDD's. It's the only way MS, decides it things stopped working (poor programing). Every time somebody talks it get recorded somewhere. Be it memory or HDD's. Heaven help you if you decide to hibernate using the SSD.
I only plan to use my SSD for static apps and storage. As little writing as possible. Hopefully I can get 5 years out of the drive.
-
If its a dual drive system, I'd put it on the normal drive. QB64 is notorious for reading a writing your whole program to disk with *each and every* keypress. This insane use of writing, rewriting, overwriting, and writing some more, isn't all that good for a SSD.
IF the system just has a SSD, but has sufficient memory, then I'd allocate 2GB or so to a persistent RAMdrive, copy QB64 to there, and run it fully out of RAM.
If neither choice is viable, you just do whatcha got to do and live with it. :P
Thee are times I wish we had the option to turn that script off. In other words, not have QB64 backup the program on every keystroke. I do appreciate the program "Recovery" it provides, and its probably linked to the "Undo" feature, too, but I don't need these features all the time.
I haven't looked into the IDE source code, probably due to my gluten intolerance. I am curious if it uses a single string for word processing. It would be very fast to binary save with that method.
Pete
-
I have the QB64 on a classic Seagate hard drive and operating system an SSD Samsung for several years and there is no problem with that. The laptop is also with SSD, there is also QB64 on SSD for about 3 or more years and everything still works nicely. SSD there is Samsung, is installed in the DVD-RW bay using a reducer. Primary harddrive there is also SSD (Kingston)
-
I have the QB64 on a classic Seagate hard drive....
There is a reason, for the statements "Batteries not included and Your mileage may vary." Ironically you can ask a launch tech about the shuttle Challenger disaster. "It flew wonderfully right up to the time it exploded."
Here was an interesting project. http://dangerousprototypes.com/blog/2010/06/18/flash-destroyer-kit-protoype/
-
Amazing isn't it? A solid-state (no moving parts) device wears out (rapidly) just by using it under normal conditions. A 7200 rpm mechanical device (think of running your car at 7200 rpm continuously) effectively never wears out! HDD amazing construction.
-
HDD amazing construction.
You never had to play with Seagates first MFM production unit. 5 Megabytes. 5mbit serial transfer speed (the part that was MFM encoded) The best part the case was 5" Full height and all plastic. Noisy to boot. BTW, plastic warps when it warms up. Fun times. Oh, best part $500 dollars apiece. 1980's money.
-
My Samsung Hard Drive it spins really fast
My SDD drive can't spin and won't last
I've got a floppy and tech support said
You need the blue pill stop taking the red
Why can't we friends...
Pete
-
You have the quality of the SSD to consider too. My main system I program on is 10yo now with 2 SSDs. been using QB64 all that time too. By comparison I lost both my 3tb HDDs after only 3 years, and they were mainly static storage(not a whole lot of adding and removing data going on).
So You will probably upgrade your system before QB64 wears out your SSDs unless you went dumbfoundedly cheep on them.
-
@doppler
As along the lines of what @SMcNeill suggests by using a RAM drive. I essentially only run QB64 off a RAM drive. I use a very different implementation of RAM drive to that of @SMcNeill. However in my implementation it takes about 7 seconds longer to start QB64 for the first time in a power up session but no wait if the computer is in sleep mode (rather than a restart).
If your SSD uses a SATA interface - you would probably notice significant speed increases (over the order of 10-17 times) compared to a spinning HDD. However if your SSD uses a PCIe interface (usually something like a M.2 drive) you may find that even greater speed increases are achieved over a SATA SSD.
RAM memory (e.g. for a RAM drive) is very much faster than SATA access however you may even find a speed performance decrease (compared to PCIe SSD).
Yes non-volatile SSD have finite write cycle lifetimes (however volatile SSD effectively supposed to have practically infinite write cycles e.g. referring to the RAM memory). A drawback of RAM memory (volatile) is if for instance the power is disconnected, the memory is lost forever - hence @SMcNeill going for persistent configuration.
On SSD vs HDD endurance - SSD (non-volatile) media relies on a Quantum physics phenomenon (spinning HDD is only a magnetic phenomenon) and the technology is relatively new (compared to magnetic technology). A big problem with the Quantum physics approach is that manufacturers are pushing the limits into memory/cost factors to make the product competitive to spinning HDD. It is well known that decreasing the size of each memory cell = small silicon die chip = statistically higher production yields. However decreasing the number of silicon atoms per memory cell causes a drastic reduction of write cycles - so as a SATA SSD is grouped into so called TBW (Tera Bytes Written), a usb flash drive (having smaller memory cells) pales into insignificance compared to say SATA SSD.
Of course if you were really wanting the ultimate non-volatile SSD, as far as TBW is concerned - there is a relatively much newer technology with significant improvements of TBW - but be prepared to spend as much as 10x $'s per byte then the better brands SSD.
On my computer I have QB64 stable build on the PCIe SSD (where Windows is) and the QB64 dev builds (which I use much more often than the stable builds) is on the RAM drive. The ram drive folder is only about 600 Mbyte for me - so I could safely get away with a 750 Mbyte RAM drive (only for QB64). The QB64 stable build (on C:\) is where ALL QB64 programs are stored only (including those from the dev builds). The RAM drive does get "hammered" by the QB64 IDE constantly rewritting of the per-keystroke editing of a program.
-
So the moral of this story is ???? ..back up your data and programs on anything other than the SSD you are using? ... or is the point being made here is that for price and speed but not longevity SSD is good, HHD is better??
-
Well presently I use a ram drive for often used and trashing programs. My present system does not use SSD (any type). The new system will be NVme. As a rule every first of the month I backup all my systems using http://www.clonezilla.org This backup has saved my butt a number of bad MS update F-UP's.
My whole point to the thread was to find out if QB64 uses other media locations. result: Doesn't. So a simple don't put QB64 on SSD would suffice.
BTW, clonezilla CERT is out of date. Just proceed ahead, it's safe and worth your time.
-
So the moral of this story is ???? ..back up your data and programs on anything other than the SSD you are using? ... or is the point being made here is that for price and speed but not longevity SSD is good, HHD is better??
The moral is...
SSD are flipping brilliant for storing resource files! Put your fonts, sounds, images on them, and your programs will read and use those resources blazingly fast. You write them once, don't change them, and accessing them has little wear on the SSD.
On the other hand, *don't* use the SSD for interactive fils, such as a swapfile. The constant reading and writing and rewriting to the file will wear out your SSD faster. Use a RAM drive, if possible, for these type of repetitive use tasks, and if not, then use the HDD instead.
Want to save an imagefor quick access? Use the SSD for that.
Want to write a file that updates a timestamp every second, overwriting the last line if no error occurred, but making a new line if one did? Use something different than a SSD for that task. The wear and tear on your drive isn't worth the slight boost in speed that you'll receive.
QB64 writes to its internal files over and over as it translates and error-checks your program with every keypress or mouseclick. It's not suitable for use with a SSD.
What would be nice for QB64, would be if we could specify in the options the path where we wanted those internal/temp files to go. Then we could set those to windows temp directory, keep them off a SSD, and yet allow users to keep QB64 itself on the SSD with no issues.
-
Thanks Doppler & Steve. By sheer luck I do not have qb64 on my ssd but this makes me think I should see what I do have on there and consider the read/write I have it undergoing. Thanks again.
-
but this makes me think I should see what I do have on there and consider the read/write I have it undergoing.
Start here. https://www.techrepublic.com/article/tech-tip-move-the-swap-file-to-another-drive/
There is also a pagefile.sys to move. It's more difficult to do it. If I say it's difficult trust me it is.
then go into the windows environment variables and create new path(s) and change label(s) to the "new path(s)"
This one is overkill : https://docs.microsoft.com/en-us/windows/deployment/usmt/usmt-recognized-environment-variables
This one is also overkill but not so convoluted like MS's : https://pureinfotech.com/list-environment-variables-windows-10/
Changing Environment locations can be costly. (like things not working at all) If you bring up a cmd prompt and enter "set" you will get an idea of the main characters to change. If in doubt do fuck with it. Be sure and follow googled procedures not BS articles.
-
Thanks again doppler.
-
Jeez, guys, aren't we exaggerating a bit? I think the moral of the story is same as it always is: don't go bleeding edge, if you want longer lifespan?
I had a 250 GB SSD in my previous work laptop, and it hung in there for more than 4 years (I kept blowing away the persistent requests to refresh, out of sheer laziness). Maybe that's the main thing. Don't go for multiple TB drives.
My new work PC's SSD is also 250 GB.
People who are packrats also demand the largest disc drives. Just as, people who have messy physical desks also have messy PC desktops. Ever noticed?
-
And why not having qb1.5 "64" on the SSD and qb 1.5 "32" on the classical HDD ?
I put QB "64" on my SSD, but exe and bas files are written on a classical HDD.
And QB "32" could be placed on a classical drive, or USB drive...
But there is a big question with theese 2 versions of QB64.
Why not having the possibility to compile either in 64bits or in 32 bits in the same program ?
I mean the QB64 "64 bits" program should propose compilation on 32 ou 64 bits...
Would it be possible once ?
-
QB64 does not cross-compile (target platforms other than what it is running on) and there are no plans to add this functionality.
-
@doppler wrote:
There is a reason, for the statements "Batteries not included and Your mileage may vary." Ironically you can ask a launch tech about the shuttle Challenger disaster. "It flew wonderfully right up to the time it exploded."
I didn't know you were a clairvoyant and you see into the future! Imagine what happened today after starting (not starting) my computer: Instead of starting Windows, only the message appeared: Disk reading error. Press Ctrl + Alt + Del to continue "
Fortunately, it was enough to bend the cables at the SSD and restart, but to be sure, I copy all programs to an external drive. Damn, I sweated!
-
@doppler wrote:
I copy all programs to an external drive. Damn, I sweated!
Go the Clonezilla route. It's mirror snapshot of your data. No need to install windows/apps and restore data. It's an all in one approach.
I am not clairvoyant, but I can predict. You will ignore my suggestion. And your computer will die a fiery death. I AM NOT TRYING TO HEX YOU.
---edit---
I have used Clonezilla on my Guinea pig computer. When I want to try before I buy software. I will go the shady route to use the full version. To see if it meets expectations. I have seen to many claims to glory, only to be burned. If the shady software was laden with "Extra Stuff". I can quickly restore from the backup and try again. If my Guinea pig computer is isolated, I have no fear off break out. The clonezilla image is the anti-vax to bring it back.
-
So the moral of this story is ???? ..back up your data and programs on anything other than the SSD you are using? ... or is the point being made here is that for price and speed but not longevity SSD is good, HHD is better??
I still say you will probably upgrade to a new system before your SSD quits.
-
I can't believe how much misinformation there is on this topic.
First, I might note that the opinions I'm expressing comes from someone with 12+ years experience specifically working with storage hardware for a major NAS / SAN company.
Let me start very simply: These ideas that all kinds of things need to be moved off an SSD are utter nonsense. That's old school thinking from before the times where the OS is SSD aware. This whole paranoia over rapid wear of an SSD is simply overblown. Even cheap consumer SSDs are highly unlikely to exceed their usage specs within 5 years.
Let's take a simple example:
I have a Seagate Firecuda 520 2TB SSD with a TBW (TeraBytes Written) rating of 3,600. Let's say I want to ensure that I get a 5 year lifespan out of this drive. This would mean that I could write 1.97 TB of data to that drive EVERY SINGLE DAY for 5 years. I don't know about you, but I don't often write that much data to a drive in a day.
Let's assume I had a 1TB SSD. That would cut the TBW rating in half which would allow for 0.98 TB written every single day for 5 years. That's still a tremendous amount of data.
As for the OS itself, any modern OS is very much SSD aware and has strategies to avoid excessive writes to the SSD. Of course, if you over tax a system, for example, trying to perform heavy video editing tasks on a system with only 4GB of RAM, you are going to force the system to utilize paging a lot more often. Spec out a system with reasonable amounts of RAM for the tasks you plan to undertake, and you might be surprised how little data gets passed through the paging system.
I'm sure that many of you have laptops that have no spinning disks, only SSDs. Have ANY of you ever actually exceeded the TBW rating of your SSD in 5 years or even 10 years???
I'm going to admit something: I was once paranoid about the short lifespans of SSDs myself. But with the advent of modern operating systems and the knowledge gained having to deal with these issues on a professional level, I now hammer away on my SSDs with reckless abandon :-)
Do I still use fixed platter HDDs? Sure. I have a media library in excess of 40TB so large fixed platter HDDs are perfect for that only because of their far better pricing for large drives, however, I may re-evaluate that soon as 8TB SSDs are starting to creep down in price.
-
I have a Seagate Firecuda 520 2TB SSD with a TBW (TeraBytes Written) rating of 3,600. Let's say I want to ensure that I get a 5 year lifespan out of this drive. This would mean that I could write 1.97 TB of data to that drive EVERY SINGLE DAY for 5 years. I don't know about you, but I don't often write that much data to a drive in a day.
Let's assume I had a 1TB SSD. That would cut the TBW rating in half which would allow for 0.98 TB written every single day for 5 years. That's still a tremendous amount of data.
https://www.tomshardware.com/reviews/best-ssds,3891.html
The thing with what you've mentioned above, needs to be put in perspective.
First, follow the link above and look at the ratings on all the best drives on the 2021 list -- the vast majority of them have *up to 1200 TBW* as their rating. That's only a third of what you're calculating for. Instead of 0.98 TB daily use (which I have no idea how you calculated that number), you're looking at 0.65 TB daily use of a 5 year lifespan. (1200 TB / 365 days / 5 years.)
(Also notice that there are several of the best rated drives on that list with only a 600TBW rating. Samsung 980, WD Blue SN550... That's half the 0.65 above, and one-sixth of the rating as on your drive.)
Now 0.65 TB *seems* like a lot, but let's take a moment to look at an interesting feature of QB64's -- the undo feature.
Do you know how undo works in QB64? I'm not 100% positive, but I *think* it's a very simple method of "write your program file over and over to disk"
For example, here's my program: PRINT "HELLO WORLD".
Undo will write an entry: P
the next entry: PR
the next entry: PRI
the next entry: PRIN
the next entry: PRINT
the next entry: PRINT "
the next entry: PRINT "H
the next entry: PRINT "HE
Each time you type a key, your whole program gets dumped to disk, so that when you hit CTRL+Z, the IDE can cycle back to the previous program state. And this is with *EACH AND EVERY KEYPRESS*.
Add to the fact that undo doesn't just record you current program's data, but also PREVIOUS programs data, up to the size of the undo buffer.
And what's the default max size of your undo buffer? 100 MB.
For the first 100MB of usage, your drive might append the data to the end of itself, not doing any overwriting, but what happens after you hit that 100MB size limit? Old data gets deleted. New data gets inserted... How's your drive handling that? Do you know?
I honestly don't have a clue, but if it's writing a 100MB undo file with each and every keystroke or mouse event I make in the IDE, then I can tell you, it's not going to take too many keypresses to hit 650 GB a day.
Writing a 100MB undo file, plus writing your whole program translated from BAS to C, with every input event leads me to thinking, "I may be old skool, but all that really doesn't sound too healthy for my SSD lifespan."
There's a lot that goes on behind the scenes with my PC that I'm not completely aware of, but there's one thing I'm certain of with QB64, and that's that if we ignore undo and its mysterious storage behavior completely, we *still* translate BAS to C with every input event -- and since it's machine translated, it's NEVER pretty.
A thousand line QB64 program might break down to translate into a 10,000 line c program... which is written to disk with *each and every* input event.
Add a line into that code:
IF foo THEN END
You just wrote 10,000 lines of c to your drive 15 times! And that's not counting typos, backspaces, or edits! Adding that ONE line into your 1000 line program just wrote 150,000 lines of c code to the drive! And what if you're the guy who, like me, works with 10,000+ line QB64 BAS files to begin with? How large is the c translation I'm tossing to disk with every keystroke??
Now, at that rate, how long will it take you to reach your 650 GB drive rating in a day? Do you *really* want that type of action on your SSD?
Personally, I don't. That's why I have 128GB of ram, with 64GB partitioned for a persistent RAM drive, and QB64 stays on it where it can write to memory all it wants without burning a hole in my drive.
-
@hanness
Adding further to what @SMcNeill mentioned above...
At the moment, not actually doing anything (editing, compiling, running) in QB64 or really anything else for that matter (except writing this reply):-
Windows Resource Monitor > Overview > Disk currently shows a total Disk activity of 100 KB/sec (sometimes peaks at 1 MB/sec) in this "idle" mode. Even at only 10KB/s this equates to 10 KB/s * ~84000 s/day = 840 MByte / day (by the fact that Windows is running). So my PCIe SSD is being pounded by almost 1 Tera Byte per day (writes) by windows alone.
Now to complicate things further - Windows resource Monitor might say for a certain PID that only 77 bytes writes /sec is happening for that PID - but the big question is how the SSD has to handle that 77 writes B/s. SSD work on a "BLOCK ERASE then BLOCK WRITE protocol" (which not being reported in technical specifications by the manufacturers, is around the 4MB per block, as independently determined by various people). Also that not a single byte can be written to a file (on a SSD, only BLOCKS) and the BLOCKS also have to work with the File Allocation unit for the files.
-
Thanks
Here is a link to work out the problems of pagefile.sys and swapfile.sys Follow it to the letter. And the system trashing on SSD will go away.
https://www.eightforums.com/threads/is-it-possible-to-move-swapfile-sys-to-a-different-volume.34544/
Since you have to remove pagefiles and reboot. Then would be the best time to remove from all drives the page file(s). Just configure one drive with a page file or at least all spinning media types as the last setup. Just make sure the SSD doesn't get assigned a pagefile.
Drive C must be the location of swapfile.sys, the trick is nothing says it must be located on drive C. The MLINK command creates a NTFS directory pointer to wherever you want. Save the link on eightforums website and follow it exactly! Unless you are a moron it's kinda foolproof. But then foolproof is only valid until the right fool shows up.
Please note: I am not reviving this thread. Let it die a slow death. Just had important good info to disseminate.
-
something i've done for years:
first all my rigs have multiple drives, recently I've replaced the OS drive with SSD, and that is all that uses it. On rare occasions, I will run some AAA game on that, but outside of that strictly OS
All my dev apps are on one (spinning) drive, many still there dating back to the early BBS's days of the '90s!!! Needless to say, that drive is bitlockered up LOL!! and all my games are on another (hey!! I'm a gamer.. what can I say. do pro work all day - its my escape hehe)
Been doing this since the '90s and my stuff is still there - I do like SSD's but the limited R/W keeps me from using the drive other than an OS' drive.
just my $0.5c worth :P
-
In my opinion, both HDD and SSD's, are amazing tech. In theory, the hard drive will never wear out (the media - not the mechanism) because technically, the heads are never in contact with the disc. SSD's have no moving parts. Apart from the potential mechanical problem with HDD's and Memory fatigue with SSD's both pieces of tech are pretty cool... But for me, I'm "old school", when it comes to Drives. HDD's for system (reliability). Suggest use SSD's for system backups/storage etc... But that's me...
I'll call your $0.05 and raise you another 5c... Moo Ha Ha....