ternal-september.org> c48e7f3a
XPost: comp.lang.pl1, comp.lang.asm.x86, comp.lang.pascal.misc
From: peter_flass@nospicedham.yahoo.com
Robert Prins wrote:
> 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
It's like the old FORTRAN or C, where you have to pass the upper bound as
an argument (lower bound always 1). PL/I and (I think Ada) don't require
this, din't know about ALGOL.
--
Pete
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
