Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.asm.x86    |    Ahh, the lost art of x86 assembly    |    4,675 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 2,855 of 4,675    |
|    Alex to Robert Prins    |
|    Re: Process at read-in time, or use post    |
|    19 Jul 17 14:45:06    |
      From: alex@nospicedham.rivadpm.com              On 19-Jul-17 14:03, Robert Prins wrote:       > This question isn't specific x86, but given that the program       > incorporating this change is mostly written in (inline) assembler, this       > might well be acceptable.       >       > It was suggested that I add three "top-10/25/40" tables to an existing       > program (yes, "that" program"), for distance, time (these two are mildly       > correlated), and velocity, where equal values are tie-broken by a second       > sort-key, velocity, distance, and distance.       >       > The current input file contains just over 4,000 records, and is unlikely       > to grow much over 5,000.       >       > The two options I seem to have is to read in the whole lot, and do three       > sorts before the generation of the three new tables, or, but I have a       > strong gut feeling, insert new max values into three tables at read-in       > time.       >       > I only a "top-1" of max values would be required, this would without a       > grain of doubt orders of magnitude faster than a final sort, and even       > generating a top-5 on-the-fly at read-in time might be faster (three       > times (up to) 20,000 compares and re-ordering five items) then a full       > blown sort, but obviously(?) generating a top-40 on the fly would be       > very expensive, both on compares and data-movement.       >       > What I have also been thinking about is a series of partial sorts, i.e.       > first sort the whole set with a reasonably efficient algorithm (Shell?)       > into two parts and repeat that process with the top-half until the final       > top-half/quarter/eight is finally sorted completely - an initial thought       > that this might also reduce the time to do the second sort (on time)       > turned out to be too optimistic one of the top time-values is in the       > bottom of the distance half.              Insertion sort at read time is your best bet.              Let's say you have N records and want a top M table. The maximum number       of compares is N*log2(M) if you keep the table max(M) in sorted order       and binary search it, and the maximum number of inserts for a worst case       already sorted input will be N, but more likely average N/2. (And       obviously, don't move records; move pointers.)              --       Alex              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca