Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
DAY 040: _TOGGLEBIT
#9
(12-19-2022, 10:03 PM)Pete Wrote: Well, I already understood the part about dooing a bit flip to change a condition. I'm just saying with the way I would code a similar function vs the way bit flipping works, hasn't convinced me I'd be gaining any performance by using this method. What's good about knowing it exists is I may find some future use for it. I seem to be using SGN() a lot these days, for example.

Pete

BITs aren't about performance.  In fact, they're very BAD at performance!!  

Imagine these two different scenarios:

1) You have to read a text string into a program.

2) You have to read a compressed string into a program, extract the contents, save them to disk, and then read the text string they produce into your program.

Now, which is going to be faster for you??



That's basically what goes on with anytime you're accessing a BIT!

It's stored in (at least) a byte.  So you load that byte in memory.  Peak inside that byte.  Count over to the bit you need information from.  Read in that one bit.  Process it.

Compared to:  Load a byte in memory.  Process it.

Bits are inefficient by their very nature.  Your program will never run faster, or better, by making use of them.

So WHY would you ever want to use them???

The same reason why you'd want to use compressed files -- to reduce overall size and memory usage.  QB64 takes up 700MB or so of disk space.  Yet, when it make it available for downloading, you get it in less than 100MB.  Less space on the servers.  Less size to send across the internet.  

But you still have to unzip that archive before you can make use of it!  Wink

That's basically BITs in a nutshell.  When you need to reduce the size of memory your program uses, you might pack a bit array to compress the amount of memory it uses.  It isn't going to make what you're doing any more EFFICIENT, but it'll reduce the space required to do what you're doing in memory or on your hard drive.

BUT, with 64-bit PCs and everyone having 8GB+ of memory available anymore, how much does one have to actually worry about compressing that memory like they used to?  Honestly, I imagine that in the next 10 years, we'll see various programming languages start to depreciate BIT usage.  I imagine Apple will be the first to decide they're no longer going to offer bit for new versions of whatever they offer developers, and after the outrage and backlash dies down, a few years later, others will follow the trend.

Bits just aren't in vogue as much as they used to be, back when folks were trying to squeeze everything they could out of 64k memory.
Reply


Messages In This Thread
DAY 040: _TOGGLEBIT - by Pete - 12-19-2022, 07:43 PM
RE: DAY 040: _TOGGLEBIT - by mnrvovrfc - 12-19-2022, 08:32 PM
RE: DAY 040: _TOGGLEBIT - by SMcNeill - 12-19-2022, 08:43 PM
RE: DAY 040: _TOGGLEBIT - by mnrvovrfc - 12-19-2022, 09:37 PM
RE: DAY 040: _TOGGLEBIT - by SMcNeill - 12-19-2022, 09:05 PM
RE: DAY 040: _TOGGLEBIT - by Pete - 12-19-2022, 09:17 PM
RE: DAY 040: _TOGGLEBIT - by SMcNeill - 12-19-2022, 09:47 PM
RE: DAY 040: _TOGGLEBIT - by Pete - 12-19-2022, 10:03 PM
RE: DAY 040: _TOGGLEBIT - by SMcNeill - 12-19-2022, 10:22 PM
RE: DAY 040: _TOGGLEBIT - by Pete - 12-19-2022, 10:30 PM
RE: DAY 040: _TOGGLEBIT - by SMcNeill - 12-19-2022, 10:42 PM
RE: DAY 040: _TOGGLEBIT - by bplus - 12-19-2022, 11:20 PM
RE: DAY 040: _TOGGLEBIT - by Pete - 12-19-2022, 11:22 PM
RE: DAY 040: _TOGGLEBIT - by Jack - 12-19-2022, 11:58 PM
RE: DAY 040: _TOGGLEBIT - by Pete - 12-20-2022, 01:11 AM
RE: DAY 040: _TOGGLEBIT - by vince - 12-20-2022, 01:59 AM
RE: DAY 040: _TOGGLEBIT - by OldMoses - 12-20-2022, 03:46 AM



Users browsing this thread: 2 Guest(s)