[TUHS] Re: Perkin-Elmer Sort/Merge II vs Unix sort(1)

[Tom Lyon <pugs78@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]

Related to the sort discussion, there's an oral history of Duane Whitlow,
founder of SyncSort, which was a big deal in IBM shops in the 70s. (and
perhaps later; I lost track)
https://archive.computerhistory.org/resources/access/text/2013/05/102702251-05-01-acc.pdf

On Sat, Jan 18, 2025 at 8:00 AM Bakul Shah via TUHS <tuhs@tuhs.org> wrote:

> On Jan 18, 2025, at 7:16 AM, Larry McVoy <lm@mcvoy.com> wrote:
> >
> > On Sat, Jan 18, 2025 at 04:51:15PM +0200, Diomidis Spinellis wrote:
> >> I'm sure the mainframe sort programs did some pretty amazing things and
> >> could run circles around the puny 830 line Unix Seventh Edition sort
> >> program.  The 215 page IBM DOS VS sort documentation that John Levine
> posted
> >> here is particularly impressive.  But I can't stop thinking that, in
> common
> >> with the mainframes these programs were running on, they represent a
> mindset
> >> that has been surpassed by superior ideas.
> >
> > I disagree.  Go back and read the reply where someone was talking about
> > sorting datasets that spanned multiple tapes, each of which was much
> > larger than local disk.  sort(1) can't begin to think about handling
> > something like that.
> >
> > I have a lot of respect for how Unix does things, if the problem fits
> > then the Unix answer is more simple, more flexible, it's better.  If
> > the problem doesn't fit, the Unix answer is awful.
> >
> > cmd < data | cmd2 | cmd3
> >
> > is a LOT of data copying.  A custom answer that did all of that in
> > one address space is a lot more efficient but also a lot more special
> > purpose.  Unix wins on flexibility and simplicity, special purpose
> > wins on performance.
>
> Mainframes had usage based pricing, not unlike what you pay for renting
> resources in the cloud, so performance really mattered. Also note that
> users use whatever computing resources they have available to get their
> job done, ideally at the lowest cost. Elegance of any OS architecture
> is secondary, if that.
>
>

[-- Attachment #2: Type: text/html, Size: 2680 bytes --]