Hi everyone
I would like some help in reducing the number of instructions required to
search a table.
The table is in no particular order, so a Binary Search may not be appropriate
here.
.
.
I will try to explain this.
.
I have a structure with X number of fields
For this example lets assume:
ST
17, 2017 8:55 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Table Searchig with a Mask
>
> Hi everyone
>
> I would like some help in reducing the number of instructions required to
search a table.
> The table is in no particular order, so a Binary Search may not b
esst...@juno.com
Sent: Saturday, June 17, 2017 11:55 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Table Searchig with a Mask
Hi everyone
I would like some help in reducing the number of instructions required to
search a table.
The table is in no particular order, so a Binary Search may not be a
gt; also.
>
>> -Original Message-
>> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
>> l...@listserv.uga.edu] On Behalf Of esst...@juno.com
>> Sent: Saturday, June 17, 2017 8:55 AM
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subject: Table Searchig w
On 2017-06-17, at 13:58, Alan Atkinson wrote:
> The time to do compares is likely to pale into insignificance compared to
> looping around a two dimensional unsorted array, unless the sizes are
> trivial...
>
> I'd be inclined to have a cli/clc pair for each element.
> I'd also be thinking har
A mask constructed for a TR with a following CLC will do
: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Table Searchig with a Mask
Hi everyone
I would like some help in reducing the number of instructions required to
search a table.
The table is in no particular order, so a Binary Search may not be appropriate
here.
.
.
I will try to explain this.
.
I have a
cache is so high?
>
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of esst...@juno.com
> Sent: Saturday, June 17, 2017 11:55 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Table Searchig with a Mask
>
> Hi ever
Richard,
>> ever appropriate on machines like the Z where the penalty for not
>> being in the cache is so high?
less for the data-cache- but even then the cache will have an
effect regardless of strategy.
and the I-cache will do have an effect regardless.
Unless the code in the search algorithm
On 19/06/17 00:32, Richard Kuebbing wrote:
Is a binary search ever appropriate on machines like the Z where the
penalty for not being in the cache is so high?
Searching a 1GB table (say, 1 million 1kB entries) via sequential
search would require loading 500MB of data into the cache on average.
That's why high performance general solutions for this type of search problem
are hard to come by.
It sounds like the original proposal was to match an input record with a small
number of fixed length fields with a table with the same layout with an unknown
number of entries. The request was
On 20 June 2017 at 12:13, Gary Weinhold wrote:
>
> But since the "*"s to indicate a wild card are at fixed locations in the
> table, a CLI should be better performance than TR or TRT.
And depending on the numbers of Structure and Array entries, and the number
of *'d elements, it may well make s
performance problem, only then would I attempt to address it.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Tony Harminc
Sent: Tuesday, June 20, 2017 11:10 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Table Searchi
tty tight loop: CLI/JE/CLC/JNE/Bump.
>
> And if I had a performance problem, only then would I attempt to address it.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Tony Harminc
On Wed, 21 Jun 2017 06:11:23 -0500, Jeffrey Celander wrote:
>If your table is large you may benefit by setting a page reference
>pattern to have the table pages prefetched for you. This only
>applies to 31-bit storage.
Really? I don't see anything in the POO that says that PFD has such
a limit
Pretty sure Jeffrey is referring to storage patterns defined by invoking the
REFPAT macro (or HLL equivalent)
Keven
> On Jun 21, 2017, at 08:14, Tom Marchant
> <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote:
>
>> On Wed, 21 Jun 2017 06:11:23 -0500, Jeffrey Celander wrote:
>>
>> If yo
16 matches
Mail list logo