From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id A2AB82DAD2 for ; Fri, 4 Oct 2024 17:40:22 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id B2E01427AB; Sat, 5 Oct 2024 01:40:19 +1000 (AEST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by minnie.tuhs.org (Postfix) with ESMTPS id 65720427A9 for ; Sat, 5 Oct 2024 01:40:09 +1000 (AEST) Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-20b0b5cdb57so24722215ad.1 for ; Fri, 04 Oct 2024 08:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728056408; x=1728661208; darn=tuhs.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=ACnKcQ3jQUAI0rGcyu55AWBbFNVN0hjXD78HrSNHsmY=; b=W5NqsM+GB5uckW3sXq6+uK5XOJl1vPmIWtW6SyFxCPcTOUgWEwgmqlzfVmLm8nv3zA SgF5toUHBJ9z1tHMbIAFvUe960rhR+ios5kaN0MBvpUA7gohSp2f6RJGhUrSrKsKPi/i ifhjhJCOvumZav0AAtunExlhHk82s5kPlIKy5765LVTefLbkE390I8IblNsMY11q5pfP IHS5oXiedeBOO9jW72eQ6YUVX6dgbnPD+MJL9qF7q68I8B5nvJ75xUenGsVfIo3YW2UO bIlBT3uxCnP2fNEx7lZ6sVwMOL4I9uDJLKWuRq7OORIe1nTf6KffolJ0C3RJe0FWme6n MxSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728056408; x=1728661208; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ACnKcQ3jQUAI0rGcyu55AWBbFNVN0hjXD78HrSNHsmY=; b=RK240K24tkbRcLr4/wKyetQZyjJ/a/jsGDdLsCtyfRHP6WawfnWZqkT+6CgX4hUO0k vgBkQOCLQVd1N80DS+usfx8BAoKRM5sQcpzpG05cZ83jvvPb/6/sH41hawsXimddLMhZ CS9/zAs3U+vuXv2LJRm74IKb7I0lM/hRMCHfj7Dek/gv4/2LPBatT8BuM4FaxyZNSOga UdAku7R2aU9rbsTfCU4DA1th1QI7TgQZweeN4FGzyrmS3n5awiWrb5tYCxTC+FTOrkHV aan0sm4uSh1id1PgiDVkv+GjzPVql1ivDz24ObTzwuILqEj+b8dobkrPT66QFJlp/k9I dYnA== X-Gm-Message-State: AOJu0YxJGC5UnO4jAvZrh2z31oYLAVYtem5D6MtgqlnotZckMzLL8x3E dxamQleJOS+dSmqJS87pez0JkhQ5f4yiOzS+tcHwUKaWxEuCeUxflvIJW+QMDQ2OtxcU2efcznb Q+9+ghlyZGZA2pQ/7cRFIyN1iiohDXw== X-Google-Smtp-Source: AGHT+IGxBY71n/OUauFk6ywXpXdkJ5wJzGnCQkMKcNSNA6IJrowjD2NwFCCwZm6p7Vgrn2+SkDPtNAK31jChz0pXcYI= X-Received: by 2002:a17:90b:108:b0:2d8:adfc:b3d3 with SMTP id 98e67ed59e1d1-2e1b35ebf10mr11333078a91.0.1728056407474; Fri, 04 Oct 2024 08:40:07 -0700 (PDT) MIME-Version: 1.0 References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> In-Reply-To: From: Paul Winalski Date: Fri, 4 Oct 2024 11:39:56 -0400 Message-ID: To: Computer Old Farts Followers Content-Type: multipart/alternative; boundary="00000000000051cbb80623a87ce7" Message-ID-Hash: Z7HTEAX5GYP35P7MKTO2YD3EWPG4SH4Q X-Message-ID-Hash: Z7HTEAX5GYP35P7MKTO2YD3EWPG4SH4Q X-MailFrom: paul.winalski@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Modern programming vs. the Good Ole Days (was Minimum Array Sizes in 16 bit C )(was Maximum) List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000051cbb80623a87ce7 Content-Type: text/plain; charset="UTF-8" A bit about my background: The first machine I programmed was ca. 1970 in high school--a Monroe programmable calculator with four registers and a maximum of 40 program steps. The most complicated thing I got it to do was to iteratively calculate factorials (of course it got arithmetic overflow pretty quickly). As an undergrad Biology major I learned BASIC on DTSS and later Fortran IV and PL/I for an S/360 model 25 (32K max memory). I decided to go into computer technology rather than Biology and attended CS grad school. I completed all the coursework but never finished my thesis. After interning at IBM's Cambridge Scientific Center for a few years, I joined DEC's software development tools group in early 1980, later joining the GEM compiler team to design and implement the non-compiler parts of the compiler back end (heap memory management, generating listing files, command line parsing, object file generation, etc.). Compaq acquired DEC and about a year later sold the Alpha chip technology--including the GEM optimizing compiler back end--to Intel. Many of the engineers--including me--went with it. I retired from Intel in 2016. One important thing I learned early on in my career at DEC is that there is a big difference between Computer Science and Software Engineering. I was very lucky that many of the top engineers in DEC's compiler group had studied at CMU--one of the few schools that taught SW Engineering skills as well as CS. I learned good SW engineering practices from the get-go. Unlike CS programming, SW engineering has to worry about things such as: o design and implementation for testability and maintainability o test system development o commenting and documentation so that others can pick up and maintain your code o algorithm scalability This thread has spent a lot of time discussing how programming has changed over the years. I bring the SW Engineering skill set up because IMO it's just as relevant today as it was in the past. Perhaps even more so. My observation is that programming style has changed in response to hardware getting faster and memory capacity getting larger. If your program has to fit into 8K or 32K you have to make every byte count--often at the expense of maintainability and algorithmic efficiency. As machines got larger and faster, programming for small size became less and less important. The first revolution along these lines was the switch from writing in machine code (assembler) to higher-level languages. Machines had become fast enough that in general it didn't matter if the compiler didn't generate the most efficient code possible. In most cases the increase in productivity (HLLs are less error-prone than assembler) and maintainability more than made up for less efficient code. The second revolution was structured programming. Machines fast enough and large enough that one didn't have to resort to rat's nest coding to make the program small and fast enough to be useful. Structured programming made code more easily understood--both by humans and by optimizing compilers. These days we have machines with several levels of data caching and multiple processor cores running asynchronously. If (as in the HPTC world) you want to get the maximum performance out of the hardware, you have to worry about framing your program in a way that can be multitasked (to take advantage of all those cores) and you have to worry about efficient cache management and interprocessor communication. The ways to do this are not always intuitively obvious. Modern optimizing compilers know all the (often completely non-intuitive) efficiency rules and can best apply them when you write your code in an algorithmically clean manner and leave the grunt work of running it efficiently on the hardware to the compiler. It's a very different world than when you had to figure out how to fit your code and data into 8K! -Paul W. --00000000000051cbb80623a87ce7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A bit about my background:=C2=A0 The first machine I = programmed was ca. 1970 in high school--a Monroe programmable calculator wi= th four registers and a maximum of 40 program steps.=C2=A0 The most complic= ated thing I got it to do was to iteratively calculate factorials (of cours= e it got arithmetic overflow pretty quickly).=C2=A0 As an undergrad Biology= major I learned BASIC on DTSS and later Fortran IV and PL/I for an S/360 m= odel 25 (32K max memory).=C2=A0 I decided to go into computer technology ra= ther than Biology and attended CS grad school.=C2=A0 I completed all the co= ursework but never finished my thesis.=C2=A0 After interning at IBM's C= ambridge Scientific Center for a few years, I joined DEC's software dev= elopment tools group in early 1980, later joining the GEM compiler team to = design and implement the non-compiler parts of the compiler back end (heap = memory management, generating listing files, command line parsing, object f= ile generation, etc.).=C2=A0 Compaq acquired DEC and about a year later sol= d the Alpha chip technology--including the GEM optimizing compiler back end= --to Intel.=C2=A0 Many of the engineers--including me--went with it.=C2=A0 = I retired from Intel in 2016.

One important thing = I learned early on in my career at DEC is that there is a big difference be= tween Computer Science and Software Engineering.=C2=A0 I was very lucky tha= t many of the top engineers in DEC's compiler group had studied at CMU-= -one of the few schools that taught SW Engineering skills as well as CS.=C2= =A0 I learned good SW engineering practices from the get-go.=C2=A0 Unlike C= S programming, SW engineering has to worry about things such as:
=
o design and implementation for testability and maintainabil= ity

o test system development

o commenting and documentation so that others can pick up and main= tain your code

o algorithm scalability
<= br>
This thread has spent a lot of time discussing how programmin= g has changed over the years.=C2=A0 I bring the SW Engineering skill set up= because IMO it's just as relevant today as it was in the past.=C2=A0 P= erhaps even more so.

My observation is that progra= mming style has changed in response to hardware getting faster and memory c= apacity getting larger.=C2=A0 If your program has to fit into 8K or 32K you= have to make every byte count--often at the expense of maintainability and= algorithmic efficiency.=C2=A0 As machines got larger and faster, programmi= ng for small size became less and less important.

= The first revolution along these lines was the switch from writing in machi= ne code (assembler) to higher-level languages.=C2=A0 Machines had become fa= st enough that in general it didn't matter if the compiler didn't g= enerate the most efficient code possible.=C2=A0 In most cases the increase = in productivity (HLLs are less error-prone than assembler) and maintainabil= ity more than made up for less efficient code.

The= second revolution was structured programming.=C2=A0 Machines fast enough a= nd large enough that one didn't have to resort to rat's nest coding= to make the program small and fast enough to be useful.=C2=A0 Structured p= rogramming made code more easily understood--both by humans and by optimizi= ng compilers.

These days we have machines with sev= eral levels of data caching and multiple processor cores running asynchrono= usly.=C2=A0 If (as in the HPTC world) you want to get the maximum performan= ce out of the hardware, you have to worry about framing your program in a w= ay that can be multitasked (to take advantage of all those cores) and you h= ave to worry about efficient cache management and interprocessor communicat= ion.=C2=A0 The ways to do this are not always intuitively obvious.=C2=A0 Mo= dern optimizing compilers know all the (often completely non-intuitive) eff= iciency rules and can best apply them when you write your code in an algori= thmically clean manner and leave the grunt work of running it efficiently o= n the hardware to the compiler.=C2=A0 It's a very different world than = when you had to figure out how to fit your code and data into 8K!

-Paul W.


--00000000000051cbb80623a87ce7--