Author Topic: Why is MrBcx going to remove $TURBO?  (Read 95 times)

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
Why is MrBcx going to remove $TURBO?
« on: September 10, 2020, 10:10:51 PM »
The word TURBO implies TURBOCHARGED -- fast and powerful, like my Ford F250 8 cylinder diesel truck.

The $TURBO directive in BCX is neither of these things.  In fact, $TURBO makes your code dangerous
and slower than if you had not used it at all.  The $TURBO directive affects the size of the array of pointers
that get allocated during runtime.  Having a larger array, means that your program will mostly request
memory when calling BCX_TmpStr. 

Conversely, when you have a small array, you will request memory the same number of times but you
will also be calling "free" to release the old memory more often, which will actually make your program
slower not faster.  As shown in the Help File under $TURBO, having a too small buffer can lead to some
nasty bugs in your programs that might be difficult to track down.

Concerning the next version of BCX, I have increased the circular buffer to hold 16k pointers.  These
pointers get dynamically allocated to different sizes as our programs are executing.  Having a larger
buffer will speed up string processing a bit but more importantly, it should make it much more rare
to experience the kind of problems mentioned earlier.  I have also added comments and renamed
several of the variables to help increase understanding.



Code: [Select]
char *BCX_TmpStr (unsigned int _Num_Bytes_)
{
  static int Indx;                  // Circular buffer index
  static char *StrFunc[16384];      // Circular buffer contains pointers
  Indx = (Indx + 1) & (16383);      // Our index will always wrap around
  if(StrFunc[Indx])                 // Is this pointer already allocated?
  {
     free (StrFunc[Indx]);          // Yes .. so free it
     StrFunc[Indx] = NULL;          // Set it to NULL
  }                                 // Request a fresh block of memory
  StrFunc[Indx] = (char*)calloc(_Num_Bytes_+1,sizeof(char));
  return StrFunc[Indx];
}

[/font]

Robert

  • Sr. Member
  • ****
  • Posts: 449
    • View Profile
Re: Why is MrBcx going to remove $TURBO?
« Reply #1 on: September 10, 2020, 11:19:16 PM »
The word TURBO implies TURBOCHARGED -- fast and powerful, like my Ford F250 8 cylinder diesel truck.

The $TURBO directive in BCX is neither of these things.  In fact, $TURBO makes your code dangerous
and slower than if you had not used it at all.  The $TURBO directive affects the size of the array of pointers
that get allocated during runtime.  Having a larger array, means that your program will mostly request
memory when calling BCX_TmpStr. 

Conversely, when you have a small array, you will request memory the same number of times but you
will also be calling "free" to release the old memory more often, which will actually make your program
slower not faster.  As shown in the Help File under $TURBO, having a too small buffer can lead to some
nasty bugs in your programs that might be difficult to track down.

Concerning the next version of BCX, I have increased the circular buffer to hold 16k pointers.  These
pointers get dynamically allocated to different sizes as our programs are executing.  Having a larger
buffer will speed up string processing a bit but more importantly, it should make it much more rare
to experience the kind of problems mentioned earlier.  I have also added comments and renamed
several of the variables to help increase understanding.



Code: [Select]
char *BCX_TmpStr (unsigned int _Num_Bytes_)
{
  static int Indx;                  // Circular buffer index
  static char *StrFunc[16384];      // Circular buffer contains pointers
  Indx = (Indx + 1) & (16383);      // Our index will always wrap around
  if(StrFunc[Indx])                 // Is this pointer already allocated?
  {
     free (StrFunc[Indx]);          // Yes .. so free it
     StrFunc[Indx] = NULL;          // Set it to NULL
  }                                 // Request a fresh block of memory
  StrFunc[Indx] = (char*)calloc(_Num_Bytes_+1,sizeof(char));
  return StrFunc[Indx];
}

[/font]

Hi MrBCX:

If a user wants less than 16384 then the user can

$TURBO 16

or from the command line

-t:16

Right ? Or are you removing that option ?


MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
Re: Why is MrBcx going to remove $TURBO?
« Reply #2 on: September 10, 2020, 11:40:51 PM »
Robert - I'm going to remove it all.

The Help file offers not one positive reason that would inform the decision to use it.

The command line switch -t:##  "works" in 7.5.4 and earlier but the $TURBO directive does not.

That's what caused me to take a fresh look at this.  It's buggy, dangerous, useless and needs to go.


Robert

  • Sr. Member
  • ****
  • Posts: 449
    • View Profile
Re: Why is MrBcx going to remove $TURBO?
« Reply #3 on: September 11, 2020, 12:05:03 AM »
Robert - I'm going to remove it all.

The Help file offers not one positive reason that would inform the decision to use it.

The command line switch -t:##  "works" in 7.5.4 and earlier but the $TURBO directive does not.

That's what caused me to take a fresh look at this.  It's buggy, dangerous, useless and needs to go.

Hi MrBCX:

i really didn't look at the code before replying to your post.

I was shocked at your decision considering all the back and forth on the Yahoo Forum discussing Mike Henning's original implementation 2004-2005.

I have just been going through those posts again but will stop as you seem to be set, (buggy, dangerous, useless and needs to go), on implementing this change.

Personally, I really don't care if $TURBO is there or not. I don't recall ever using $TURBO for any code except for testing.

And, if it doesn't work as is, there is really nothing more to say.


MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
Re: Why is MrBcx going to remove $TURBO?
« Reply #4 on: September 11, 2020, 12:57:49 AM »
I reviewed the initial 2004 posts.  Two things jumped out.

1) Mike's 2004 implementation was different in several ways - notably he used realloc instead of free/calloc
 
2) Mike stated compile times for BCX went from 8.25 secs - 4.5 secs.
In 2004, machines were much slower than today, so that 50% improvement was impressive.
Today, my 8-year-old PC (I5 quad core) translates BCX in just over half a second.
I imagine your Ryzen 7 probably borders on forward time-travel when you compile BCX.


 

Robert

  • Sr. Member
  • ****
  • Posts: 449
    • View Profile
Re: Why is MrBcx going to remove $TURBO?
« Reply #5 on: September 11, 2020, 01:23:12 AM »
I reviewed the initial 2004 posts.  Two things jumped out.

1) Mike's 2004 implementation was different in several ways - notably he used realloc instead of free/calloc
 
2) Mike stated compile times for BCX went from 8.25 secs - 4.5 secs.
In 2004, machines were much slower than today, so that 50% improvement was impressive.
Today, my 8-year-old PC (I5 quad core) translates BCX in just over half a second.
I imagine your Ryzen 7 probably borders on forward time-travel when you compile BCX.

I'm glad you looked at that.

6.2.4 was the end of it. As with so many other things 6.5.0 put an end to it.

Even so, nobody, ever, was able to figure out why in some circumstances those +128 kludges were needed.  They just worked ???

Robert

  • Sr. Member
  • ****
  • Posts: 449
    • View Profile
Re: Why is MrBcx going to remove $TURBO?
« Reply #6 on: September 11, 2020, 01:31:56 AM »
I reviewed the initial 2004 posts.  Two things jumped out.

1) Mike's 2004 implementation was different in several ways - notably he used realloc instead of free/calloc
 
2) Mike stated compile times for BCX went from 8.25 secs - 4.5 secs.
In 2004, machines were much slower than today, so that 50% improvement was impressive.
Today, my 8-year-old PC (I5 quad core) translates BCX in just over half a second.
I imagine your Ryzen 7 probably borders on forward time-travel when you compile BCX.

The Ryzen 7 is no faster than your machine, 0.59 seconds for a translation running 64 bit compiled MSVC or Pelles.  I think the default is SSE2, maybe I should see if compiling for AVX256 makes any difference.