|
Ok that answered my question. A few years ago I did some benchmarking on setll vs lokup vs RPG binary search vs C binary search in a sorted array with the ascend keyword. Both binary searches were faster than lokup or setll. Can't remember the numbers, but it was around one order of magnitude. I haven't been able to write a binary search in RPG that's faster than the C function, although the difference isn't dramatic. That may be my problem. <g> > -----Original Message----- > From: Joe Pluta [mailto:joepluta@PlutaBrothers.com] > Sent: Monday, December 03, 2001 7:06 AM > To: midrange-l@midrange.com > Subject: RE: array handling > > > > -----Original Message----- > > From: jt > > > > But you said ASCEND causes a binary search...?!? Sheesh... > When did THAT > > happen...?!? (I'd always thought it still used sequential > search, and > > ASCEND just allowed for *LT or *GT type lookups.) That'd > be two things, > > today...:-) > > I have to eat a substantial bit of crow here, JT. I did the > one thing I > hate most - I typed in an assumption as fact. I was told > this way back in > the early days of my programming career, and I honestly never > bothered to > check it, I assumed it was so because it made such good > sense. It made > sense to me that IBM, with all their knowledge in writing > compilers, would > indeed be smart enough to use something as fundamentally > sound as a binary > search algorithm, but this turns out not to be true, at least > from empirical > evidence. > > Modifying my test program to compare the times of a lookup on > an acending > array and a lookup on a non-ascending array yielded exactly the same > results, even after 5,000,000 repetitions. In my copious > free time, I might > try to check the generated MI code, but the actual test shows > me that the > code is exactly the same for each one. > > Just trying to set the record straight. > > _______________________________________________
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.