XPost: comp.lang.asm.x86, comp.lang.pl1, comp.lang.pascal.misc   
   From: robert@nospicedham.prino.org   
      
   On 2018-08-17 19:20, Robert Prins wrote:   
   > On 2018-08-17 06:49, Terje Mathisen wrote:   
   >> Robert Prins wrote:   
   >>> On 2018-08-16 16:02, Terje Mathisen wrote:   
   >>>> (newsgroups limited to just clax86, my server does not allow   
   indiscriminate   
   >>>> cross-posting.)   
      
      
      
   > Obviously I could cater for this, but while we've got this discussion going,   
   > I've decided to try filling the entire top-N in the "caching" code, where I   
   end   
   > up going to nearly the bottom, entry 4,300 of (currently) 4,310 rides,   
   anyway. A   
   > quick test using the old PL/I version, where I can use a compiler option that   
   > tells me how many times each statement is executed, tells me that the   
   executed   
   > statement count is reduced by more than 90% when I use this approach for the   
   > Top-10s of trips. ;)   
   >   
   > Only unpleasant side issue is the fact that I'm using 3-D arrays,   
   >   
   > dcl 1 t10_trip(trip_total.trip) ctl,   
   >        2 tr_ix(3)        fixed bin (31) init ((3)0),   
   >        2 tr_ktv(3, 10)   ptr;   
   >   
   > with   
   >   
   > #j = t10_trip(lift_list.trip).tr_ix(1) + 1;   
   > if #j <= hbound(tr_ktv, 3) then   
   >    t10_trip(lift_list.trip).tr_ktv(1, #j) = lift_ptr;   
   >   
   > t10_trip(lift_list.trip).tr_ix(1) = #j;   
   >   
   > to fill the top-10 slots, and worse for the Type/Country/Nat tables where I   
   > have to do a lookup of the index. (Which leads to the question, is there a   
   > way using all the new whiter than white x86 instructions to fast match a   
   > 4-byte value in an array of up to (potentially) 234 values? I'm now using the   
   > "vpcmpistri" (see another tread) to find CR's in the buffer (and don't   
   > understand why I require a VPXOR or set them to 0x00), and similar code would   
   > probably faster than a discretely coded version of CMPSD...)   
   >   
   > which won't result in pretty code using Virtual Pascal.   
      
   Needlessly to say, the VP generated code is ugly as (insert your favourite   
   expletive)!   
      
   > Need to check what Enterprise PL/I generates, but even here, based on past   
   > experience, I'm somewhat pessimistic.   
      
   And this code seems to be pretty good using Enterprise PLI V4.5.0. Would need   
   use another system to see what Enterprise PL/I V5.2.2 generates.   
      
   Running time with VP generated code is around 5% less than old (find only   
   top-of-sublist) code. ;) Now just have to hack it into something more   
   palatable.   
      
   One feature sadly missing from Pascal is the fact that PL/I allows you to use   
   '*' as array extents in a called proc, and the (hidden) descriptors that are   
   also passed to it allow you to call the same proc with   
      
   dcl 1 t10_summ(1) ctl,   
          2 su_ix(3)        fixed bin (31),   
          2 su_ktv(3,50)    ptr;   
      
   dcl 1 t10_trip(trip_total.trip) ctl,   
          2 tr_ix(3)        fixed bin (31),   
          2 tr_ktv(3,10)    ptr;   
      
   dcl 1 t10_cnty(0:lift_work.#cnty) ctl,   
          2 co_ix(3)        fixed bin (31),   
          2 co_ktv(3,10)    ptr;   
      
   dcl 1 t10_year(year_top -> year_list.year:   
                   year_end -> year_list.year) ctl,   
          2 yr_ix(3)        fixed bin (31) init ((3)0),   
          2 yr_ktv(3,10)    ptr;   
      
   and a set of builtin functions (lbound and hbound) can be used to retrieve the   
   low and high bounds of the arrays. ;) It's a bit more convoluted to do this   
   with   
   Pascal...   
      
   Robert   
   --   
   Robert AH Prins   
   robert(a)prino(d)org   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)