Hi,

Well basically there is a working version in javascript in c++ one would
require that the search string double different null-terminated string or
basically one requires 2 resolution values to be reserved for the special
meaning of null or end of data, where the correct ones could be used to
terminate
data such one could get a slight performance increase in these cases.

Typically, don't' have to compute the end range and neither have to check
it each match on for characters that don't match and if there are a lot of
partial matches, then you are winning,
as partial matches are only one character.

But clearly one can't do this optimization any further without some tricks
like above and that those values typically have reserved usage, otherwise
things break, which means like the cleansing of external data would be
required for the
last value to ensure its escape.

So I guess ultimately one would like to be able to range check a statement
in parallel, to avoid an encoding schema problem, masync or mparrel{
if(str[k] == strJohn[i] & k < maxK)..}

So I guess just the bitmapPtr and ability to use continue and break skip
with labels and maybe this. Will have to get into the arm spesification.

https://es.discourse.group/t/achive-higher-performent-solutions-with-greater-high-level-control-of-break-num-label-continue-skip-equivalent-of-low-level-goto-with-block-chain-of-statments/619/6


Cleansing:

function johnMary(str, strJohn) {

  str +="\0";
// add a sentinal, as john out of bounds is undefined, which is not
equal to John.


// If the string was really long, this this would have a performance
increase and deal with john being able to have null terminate in it.
    // Else

// One requires a different double null terminator, so one require 2
resolution value of the string to be searched and one for the smaller
string.
    let i = strJohn.length -1;
    do {
      if (strJohn[i] !=='\0') {
        str += strJohn.substring(i+1);
        break;
      }
      i--;
    } while(i >= 0)


  let countJohn = 0;

    main:for(let i = 0; i < str.length; i++) {

      for (let j = 0, k = i; true; j++, k++) {
        if (str[k] !== strJohn[j]){
          if (strJohn[j] === undefined) {
            countJohn++;
          }
          continue main;
        }
      }
    }

    return countJohn
  }

  let s = "John\0John\0";
  console.log(johnMary(s, "John\0"));

---
function match(char* str) {
char* matchme = "matchme\0";
let countMatch = 0;
for(char* ch = str, char chd = ch*;chd != '\0';ch++, chd = *ch)
{
  // could make this an inline function.
  char* chs = str, char chds   = chs*;
  char* mech = matchme, char mechd = *mech ;
  while(true)  { // sure that by now compiler optermized, could just say
loop
     if (chds != mechd) {
        if(mechd == '\0')   {
           break;
          continue; // kicks out of the loop and skip the rest of the
parent look code, for a case that fail, in the case of successfully match,
then countMatch++ will execute.
       }
     }
  mech++; mechd = * mech;    chs++; chds = *chs ;
  }
  countMatch++;
}
}
On Mon, Jan 18, 2021 at 6:21 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Monday, 18 January 2021 00:12:18 PST Wesley Oliver via Std-Proposals
> wrote:
> > Hi,
> >
> > I would like to look at how to achieve the same performance that c++
> would
> > be capable of achieving with characters that are '\0' terminate
> physically
> > by there last data position. Because data that is null terminate, doesn't
> > require range checking.
>
> That's an incorrect statement. Just because the bounds are implicit does
> not
> mean range checking is optional. Anywhere where range checking should have
> been done, it still needs to be done. The only difference is that you must
> calculate the range before doing the checking.
>
> As a consequence of having to iterate to find the boundary, some
> operations
> become different.
>
> But it's not true that implicit termination or termination by sentinel
> makes
> things faster. In fact, from experience, it's quite the opposite. So
> you'll
> need to prove your hypothesis with data if it is the motivation factor for
> this.
>
> > So my question is how could we improve things, such that the typically
> > conditional bounds checking statements for int array or similar could be
> > reduce or written in slightly different form,
> > such that we can achieve the same performance as null terminated data.
>
> Please consider that "achieve the same performance as null-terminated
> data"
> currently means "reducing performance". It's not what you want.
>
> > For this to happen, it would require improved compiler and also
> > hypothetically invisigaing new cpu wiring or logic, that in 2025 years
> time
> > would give us massive performance boost, as we have figure out how to
> write
> > could that has many performance knocks in better way, by reduction or
> what
> > every that technic is, to reduce the number of instructions required.
>
> Investigating a new CPU is out of scope. Moreover, I don't think you've
> investigated CPUs sufficiently, since they do run superscalar and
> pipelined,
> meaning they will run a few instructions ahead. For example, you said:
>
> > So the ideas I have from above, would be conditional statements that
> could
> > be parralized, with out changing the logic of the program. so think that
> > both
> > numArray[i] == numArray2[j]
> > i < maxlen
>
> They ALREADY are parallelised today. Like I said, I don't think you've
> done
> enough investigation of current CPUs before making this proposal. If you
> want
> to talk about how to improve CPUs, aside from locating the right people to
> talk to, you need to come with hard data showing where they can do better
> and
> where time is spent in overhead. Similalry, if you want to get compilers
> to
> improve, show some hard numbers on how they are not using the existing CPU
> capabilities to the full extent.
>
> From experience talking to CPU architects (and I have!), they have enough
> areas to currently address that can improve code by more than 1%. So your
> barrier to get their attention is to show that they could get at least
> that
> much.
>
> > function match(char* str) {
> >
> > char* matchme = "matchme\0";
> >
> > let countMatch = 0;
> >
> > for(char* ch = str, char chd = ch*;chd != '\0';ch++, chd = *ch)
> > {
> >   // could make this an inline function.
> >
> >   char* chs = str, char chds   = chs*;
> >   char* mech = matchme, char mechd = *mech ;
> >   while(true)  { // sure that by now compiler optermized, could just say
> > loop
> >      if (chds != mechd) {
> >         if(mechd == '\0')   {
> >            break;
> >           continue; // kicks out of the loop and skip the rest of the
> > parent look code, for a case that fail, in the case of successfully
> match,
> > then countMatch++ will execute.
> >        }
> >      }
> >   mech++; mechd = * mech;    chs++; chds = *chs ;
> >   }
> >   countMatch++;
> > }
> > }
>
> One other thing: if you're going to post code for which performance can be
> imiproved, you have to start with the state of the art. Your code above
> for
> substring matching is not the most optimal today.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel DPG Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
-- 
----
GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.olis_at_[hidden]