Author Topic: Getting new computer with SSD, where to put QB64, are there gotcha's  (Read 593 times)

0 Members and 1 Guest are viewing this topic.

Offline doppler

  • Forum Regular
  • Posts: 219
Re: Getting new computer with SSD, where to put QB64, are there gotcha's
« Reply #15 on: October 13, 2021, 10:05:17 AM »
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.

Online SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3452
    • Steve’s QB64 Archive Forum
Re: Getting new computer with SSD, where to put QB64, are there gotcha's
« Reply #16 on: October 13, 2021, 11:29:51 AM »
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.
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Dimster

  • Seasoned Forum Regular
  • Posts: 389
Re: Getting new computer with SSD, where to put QB64, are there gotcha's
« Reply #17 on: October 13, 2021, 12:16:01 PM »
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.

Offline doppler

  • Forum Regular
  • Posts: 219
Re: Getting new computer with SSD, where to put QB64, are there gotcha's
« Reply #18 on: October 13, 2021, 03:41:45 PM »
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.


Offline Dimster

  • Seasoned Forum Regular
  • Posts: 389
Re: Getting new computer with SSD, where to put QB64, are there gotcha's
« Reply #19 on: October 13, 2021, 04:06:12 PM »
Thanks again doppler.

Offline Bert22306

  • Forum Regular
  • Posts: 200
Re: Getting new computer with SSD, where to put QB64, are there gotcha's
« Reply #20 on: October 13, 2021, 11:36:42 PM »
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?

Offline euklides

  • Forum Regular
  • Posts: 120
Re: Getting new computer with SSD, where to put QB64, are there gotcha's
« Reply #21 on: October 14, 2021, 08:36:24 AM »
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 ?
Why not yes ?

Offline luke

  • QB64 Developer
  • Seasoned Forum Regular
  • Posts: 284
Re: Getting new computer with SSD, where to put QB64, are there gotcha's
« Reply #22 on: October 14, 2021, 09:31:47 AM »
QB64 does not cross-compile (target platforms other than what it is running on) and there are no plans to add this functionality.

Offline Petr

  • Forum Resident
  • Posts: 1598
  • The best code is the DNA of the hops.
Re: Getting new computer with SSD, where to put QB64, are there gotcha's
« Reply #23 on: October 14, 2021, 10:33:45 AM »

@doppler wrote:

Quote
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!

Offline doppler

  • Forum Regular
  • Posts: 219
Re: Getting new computer with SSD, where to put QB64, are there gotcha's
« Reply #24 on: October 14, 2021, 01:05:53 PM »
@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.
« Last Edit: October 14, 2021, 01:13:52 PM by doppler »

Offline Cobalt

  • QB64 Developer
  • Forum Resident
  • Posts: 748
  • At 60 I become highly radioactive!
Re: Getting new computer with SSD, where to put QB64, are there gotcha's
« Reply #25 on: October 14, 2021, 08:13:04 PM »
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.
Granted after becoming radioactive I only have a half-life!

Offline hanness

  • Forum Regular
  • Posts: 201
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.



Online SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3452
    • Steve’s QB64 Archive Forum
Quote
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.
« Last Edit: Yesterday at 05:51:14 AM by SMcNeill »
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Richard

  • Seasoned Forum Regular
  • Posts: 354
@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.



« Last Edit: Yesterday at 10:17:17 AM by Richard »