Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #148509 > unrolled thread
| Started by | jmfbahciv <See.above@aol.com> |
|---|---|
| First post | 2015-07-19 13:25 +0000 |
| Last post | 2015-07-23 06:40 +1000 |
| Articles | 20 on this page of 75 — 19 participants |
Back to article view | Back to alt.folklore.computers
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-19 13:25 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-20 13:29 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 Tim Streater <timstreater@greenbee.net> - 2015-07-20 14:42 +0100
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-21 12:53 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 Lon <lon.stowell@comcast.net> - 2015-07-20 07:50 -0600
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-21 05:46 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-20 13:29 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 Andrew Swallow <am.swallow@btinternet.com> - 2015-07-20 16:13 +0100
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-21 12:53 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 Tim Streater <timstreater@greenbee.net> - 2015-07-21 14:01 +0100
Re: 1973--TI 8 digit electric calculator--$99.95 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-07-21 14:42 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 Tim Streater <timstreater@greenbee.net> - 2015-07-21 15:53 +0100
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-22 12:20 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-22 12:20 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 Andrew Swallow <am.swallow@btinternet.com> - 2015-07-22 16:58 +0100
Re: 1973--TI 8 digit electric calculator--$99.95 Peter Flass <peter_flass@yahoo.com> - 2015-07-22 16:07 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 Ahem A Rivet's Shot <steveo@eircom.net> - 2015-07-22 19:35 +0100
Re: 1973--TI 8 digit electric calculator--$99.95 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-07-30 22:50 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 Ahem A Rivet's Shot <steveo@eircom.net> - 2015-07-31 09:00 +0100
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-23 12:22 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-24 05:52 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-23 06:41 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-22 12:20 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 hancock4@bbs.cpcn.com - 2015-07-22 07:25 -0700
Re: 1973--TI 8 digit electric calculator--$99.95 Peter Flass <peter_flass@yahoo.com> - 2015-07-22 16:02 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 hancock4@bbs.cpcn.com - 2015-07-22 10:20 -0700
Re: 1973--TI 8 digit electric calculator--$99.95 Morten Reistad <first@last.name.invalid> - 2015-07-22 19:37 +0200
Re: 1973--TI 8 digit electric calculator--$99.95 Gene Wirchenko <genew@telus.net> - 2015-07-23 15:37 -0700
Re: 1973--TI 8 digit electric calculator--$99.95 Morten Reistad <first@last.name.invalid> - 2015-07-24 01:17 +0200
Re: 1973--TI 8 digit electric calculator--$99.95 Gene Wirchenko <genew@telus.net> - 2015-07-24 11:12 -0700
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-24 11:52 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 Morten Reistad <first@last.name> - 2015-07-24 18:01 +0200
Re: 1973--TI 8 digit electric calculator--$99.95 Peter Flass <peter_flass@yahoo.com> - 2015-07-24 20:41 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 Dan Espen <despen@verizon.net> - 2015-07-24 17:06 -0400
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-25 12:42 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 Peter Flass <peter_flass@yahoo.com> - 2015-07-25 14:13 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 lawrence@cluon.com - 2015-07-27 03:00 +0200
Re: 1973--TI 8 digit electric calculator--$99.95 Peter Flass <peter_flass@yahoo.com> - 2015-07-27 14:08 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 Anne & Lynn Wheeler <lynn@garlic.com> - 2015-07-27 08:43 -0700
Re: 1973--TI 8 digit electric calculator--$99.95 Anne & Lynn Wheeler <lynn@garlic.com> - 2015-07-27 13:56 -0700
Re: 1973--TI 8 digit electric calculator--$99.95 Ahem A Rivet's Shot <steveo@eircom.net> - 2015-07-25 17:23 +0100
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-26 05:49 +1000
Re: process accounting, was 1973--TI 8 digit electric calculator--$99.95 scott@slp53.sl.home (Scott Lurndal) - 2015-07-27 13:24 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 Morten Reistad <first@last.name.invalid> - 2015-07-25 16:30 +0200
Re: 1973--TI 8 digit electric calculator--$99.95 sidd@situ.com (sidd) - 2015-07-26 01:05 -0400
Re: 1973--TI 8 digit electric calculator--$99.95 scott@slp53.sl.home (Scott Lurndal) - 2015-07-27 13:23 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-30 16:24 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-23 12:22 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-24 05:58 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-23 12:22 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-24 05:58 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-07-30 22:50 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 "JHY" <JHY5566@nospam.com> - 2015-07-31 14:00 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 Ahem A Rivet's Shot <steveo@eircom.net> - 2015-07-31 09:06 +0100
Re: 1973--TI 8 digit electric calculator--$99.95 Morten Reistad <first@last.name.invalid> - 2015-07-22 15:26 +0200
Re: 1973--TI 8 digit electric calculator--$99.95 hancock4@bbs.cpcn.com - 2015-07-22 09:53 -0700
Re: 1973--TI 8 digit electric calculator--$99.95 Tim Streater <timstreater@greenbee.net> - 2015-07-22 18:23 +0100
Re: 1973--TI 8 digit electric calculator--$99.95 "JHY" <JHY5566@nospam.com> - 2015-07-23 06:08 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 Morten Reistad <first@last.name.invalid> - 2015-07-22 22:44 +0200
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-23 06:38 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-23 12:22 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-24 05:57 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 Andrew Swallow <am.swallow@btinternet.com> - 2015-07-24 02:07 +0100
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-24 11:43 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 Morten Reistad <first@last.name.invalid> - 2015-07-24 00:54 +0200
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-24 10:21 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 Andrew Swallow <am.swallow@btinternet.com> - 2015-07-24 02:15 +0100
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-24 11:46 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 Quadibloc <jsavard@ecn.ab.ca> - 2015-07-24 05:59 -0700
Re: 1973--TI 8 digit electric calculator--$99.95 Quadibloc <jsavard@ecn.ab.ca> - 2015-07-24 06:00 -0700
Re: 1973--TI 8 digit electric calculator--$99.95 Quadibloc <jsavard@ecn.ab.ca> - 2015-07-22 11:19 -0700
Re: 1973--TI 8 digit electric calculator--$99.95 "JHY" <JHY5566@nospam.com> - 2015-07-23 06:26 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 jmfbahciv <See.above@aol.com> - 2015-07-23 12:22 +0000
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-24 05:51 +1000
Re: 1973--TI 8 digit electric calculator--$99.95 "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-23 06:40 +1000
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2015-07-24 05:52 +1000 |
| Message-ID | <d1cv0bFgqjjU1@mid.individual.net> |
| In reply to | #148858 |
"jmfbahciv" <See.above@aol.com> wrote in message news:PM00051B8A1AAF2A41@aca24c78.ipt.aol.com... > Andrew Swallow wrote: >> On 22/07/2015 13:20, jmfbahciv wrote: >>> Andrew Swallow wrote: >>>> On 21/07/2015 15:42, Charlie Gibbs wrote: >>>>> On 2015-07-21, Tim Streater <timstreater@greenbee.net> wrote: >>>>> >>>>>> In article <PM00051B623040E297@aca42ea8.ipt.aol.com>, jmfbahciv >>>>>> <See.above@aol.com> wrote: >>>>>> >>>>>>> Andrew Swallow wrote: >>>>>>> >>>>>>>> It could just as easily have been described as being in the >>>>>>>> operating >>>>>>>> system business, each of which came with some free hardware. >>>>>>> >>>>>>> No. We didn't make money on OSes. >>>>>>> >>>>>>> No; that was not the business plan. Our tradeoffs were always based >>>>>>> on hardware being the primary business, not software. >>>>>> >>>>>> Doomed in the long run, then. It was never gonna compete with >>>>>> low-cost >>>>>> generic hardware. >>>>> >>>>> Perhaps. But few could have forseen how hardware prices would drop. >>>>> In the '60s and '70s hardware was _expensive_. >>>>> >>>>>> And what's the point of selling hardware with no software? People buy >>>>>> computers to use as tools, not to write bespoke software on, >>>>>> certainly >>>>>> not at least if the bespoke software they're writing is 99% the same >>>>>> as >>>>>> the guy's next door. >>>>> >>>>> In the '70s hardware and software had not yet been homogenized. >>>>> Hardware was much more expensive than people ($150/hour for about >>>>> as much CPU power as a Commodore 64, programmed by people making >>>>> $10/hour). Everybody developed software in-house, and tailored >>>>> it exactly to their needs. If you had proposed the current paradigm >>>>> of force-fitting your application to off-the-shelf software - even >>>>> if such was available - you'd be laughed out of the room. >>>>> >>>>> You can't judge 1970 practices from a 2015 viewpoint. >>>>> >>>> >>>> We can however judge 1980s practices from a 1980s viewpoint. >>>> >>>> An LSI-11 on every desk and VAX in each department. >>> >>> Not the early 80s. >>> >>> /BAH >>> >> It was possible, the first LSI-11s were late 70s. > There is a difference between what was possible and what happened. That happened, I did it myself. > It takes time for outside world to rethink their computing usage. We in fact drove that, DEC didn’t.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2015-07-23 06:41 +1000 |
| Message-ID | <d1adfbFrpmjU1@mid.individual.net> |
| In reply to | #148777 |
"jmfbahciv" <See.above@aol.com> wrote in message news:PM00051B75F11EAFDE@aca40d0e.ipt.aol.com... > Andrew Swallow wrote: >> On 21/07/2015 15:42, Charlie Gibbs wrote: >>> On 2015-07-21, Tim Streater <timstreater@greenbee.net> wrote: >>> >>>> In article <PM00051B623040E297@aca42ea8.ipt.aol.com>, jmfbahciv >>>> <See.above@aol.com> wrote: >>>> >>>>> Andrew Swallow wrote: >>>>> >>>>>> It could just as easily have been described as being in the operating >>>>>> system business, each of which came with some free hardware. >>>>> >>>>> No. We didn't make money on OSes. >>>>> >>>>> No; that was not the business plan. Our tradeoffs were always based >>>>> on hardware being the primary business, not software. >>>> >>>> Doomed in the long run, then. It was never gonna compete with low-cost >>>> generic hardware. >>> >>> Perhaps. But few could have forseen how hardware prices would drop. >>> In the '60s and '70s hardware was _expensive_. >>> >>>> And what's the point of selling hardware with no software? People buy >>>> computers to use as tools, not to write bespoke software on, certainly >>>> not at least if the bespoke software they're writing is 99% the same as >>>> the guy's next door. >>> >>> In the '70s hardware and software had not yet been homogenized. >>> Hardware was much more expensive than people ($150/hour for about >>> as much CPU power as a Commodore 64, programmed by people making >>> $10/hour). Everybody developed software in-house, and tailored >>> it exactly to their needs. If you had proposed the current paradigm >>> of force-fitting your application to off-the-shelf software - even >>> if such was available - you'd be laughed out of the room. >>> >>> You can't judge 1970 practices from a 2015 viewpoint. >>> >> >> We can however judge 1980s practices from a 1980s viewpoint. >> >> An LSI-11 on every desk and VAX in each department. > > Not the early 80s. Yep, I did that myself in the late 70s.
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2015-07-22 12:20 +0000 |
| Message-ID | <PM00051B75E9682BEF@aca40d0e.ipt.aol.com> |
| In reply to | #148703 |
Tim Streater wrote: > In article <PM00051B623040E297@aca42ea8.ipt.aol.com>, jmfbahciv > <See.above@aol.com> wrote: > >>Andrew Swallow wrote: > >>> It could just as easily have been described as being in the operating >>> system business, each of which came with some free hardware. >> >>No. We didn't make money on OSes. >> >>No; that was not the business plan. Our tradeoffs were always based >>on hardware being the primary business, not software. > > Doomed in the long run, then. It was never gonna compete with low-cost > generic hardware. > > And what's the point of selling hardware with no software? You are assuming that all hardware was sold as _systems_. this was not the case until about 1980. > People buy > computers to use as tools, not to write bespoke software on, certainly > not at least if the bespoke software they're writing is 99% the same as > the guy's next door. The "computer as a tool" didn't happen until the mid-80s when PCs became cheap enough for Joe Shmoe to buy and use. /BAH
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2015-07-22 07:25 -0700 |
| Message-ID | <fa5d24e3-9253-4544-864b-5109eed181f0@googlegroups.com> |
| In reply to | #148778 |
On Wednesday, July 22, 2015 at 8:20:09 AM UTC-4, jmfbahciv wrote: > The "computer as a tool" didn't happen until the mid-80s when PCs became > cheap enough for Joe Shmoe to buy and use. Computers were invented and used from the inception as tools. Like other tools, they evolved over time to become more user friendly and affordable.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2015-07-22 16:02 +0000 |
| Message-ID | <953067555459273410.965461peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #148782 |
<hancock4@bbs.cpcn.com> wrote: > On Wednesday, July 22, 2015 at 8:20:09 AM UTC-4, jmfbahciv wrote: > >> The "computer as a tool" didn't happen until the mid-80s when PCs became >> cheap enough for Joe Shmoe to buy and use. > > Computers were invented and used from the inception as tools. Like other > tools, they evolved over time to become more user friendly and affordable. At least until the 60's most people buying a computer expected to do or contract for most of the programming (which is what paid my salary for many years). There was some off-the-shelf software, but, as someone said, the idea that a company would change its procedures to conform to the software rather than change the software to fit was very foreign. Most of the purchasable software available was special-purpose, like Syncsort instead of IBM's sort, or technical applications like linear programming of circuit analysis stuff. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2015-07-22 10:20 -0700 |
| Message-ID | <fda5db27-4194-4b69-aebc-5676f023d214@googlegroups.com> |
| In reply to | #148790 |
On Wednesday, July 22, 2015 at 12:04:30 PM UTC-4, Peter Flass wrote: > At least until the 60's most people buying a computer expected to do or > contract for most of the programming (which is what paid my salary for many > years). There was some off-the-shelf software, but, as someone said, the > idea that a company would change its procedures to conform to the software > rather than change the software to fit was very foreign. Most of the > purchasable software available was special-purpose, like Syncsort instead > of IBM's sort, or technical applications like linear programming of circuit > analysis stuff. In the tab machine era, IBM prepared a lot of applications for its customers. For instance, back in the 1930s they had a comprehensive railroad accounting system, that handled freight car rental payments and receipts, station rents, and other situations unique to railroading. In the 1950s, IBM supported conferences for its customers to share software (and the group became SHARE). Originally, this was the most basic stuff, like assemblers and utilities, but grew to include applications. (writeups are on bit savers). In the 1960s, IBM developed application software. As mentioned, a popular 1401 (and later S/360) system was a hospital accounting package. Back then software and hardware were bundled, it was hard for independent companies to compete. But after IBM unbundled, software houses, both application and utility (e.g. syncsort), exploded. For things like payroll, it was a tough call. On the one hand, payroll is a complex application, and developing in house in a relatively small organization is costly. On the other hand, buying a canned routine has a purchase cost and usually a tough customization cost. For very small businesses, service bureaus did the work, taking advantages of economy of scale, enriching Frank Lautenberg. Today there is SAP. I hate to admit it, but I have no idea what that is. So it goes. (I probably should not apply for jobs calling for a "SAP specialist".
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name.invalid> |
|---|---|
| Date | 2015-07-22 19:37 +0200 |
| Message-ID | <n0158c-eoj.ln1@sambook.reistad.name> |
| In reply to | #148790 |
In article <953067555459273410.965461peter_flass-yahoo.com@news.eternal-september.org>, Peter Flass <peter_flass@yahoo.com> wrote: ><hancock4@bbs.cpcn.com> wrote: >> On Wednesday, July 22, 2015 at 8:20:09 AM UTC-4, jmfbahciv wrote: >> >>> The "computer as a tool" didn't happen until the mid-80s when PCs became >>> cheap enough for Joe Shmoe to buy and use. >> >> Computers were invented and used from the inception as tools. Like other >> tools, they evolved over time to become more user friendly and affordable. > >At least until the 60's most people buying a computer expected to do or >contract for most of the programming (which is what paid my salary for many >years). There was some off-the-shelf software, but, as someone said, the >idea that a company would change its procedures to conform to the software >rather than change the software to fit was very foreign. Most of the >purchasable software available was special-purpose, like Syncsort instead >of IBM's sort, or technical applications like linear programming of circuit >analysis stuff. And, remember, the software of 40-50 years ago was a lot simpler than what we use today. A modern payroll system has several tens of thousands of item types for labour. A 60s version may have had upper tens of them, as implented by some dedicated programmer for a special place. It was also very common to have limitations in the computer coding, where the operators had to coerce some input values to get the results that were desired. This is all but gone now. An example, from todays work schedule: Building emacs on my display computer, a 4-core arm7 with SSD and 4x1.7Ghz cpus each measuring just short of 4 bips with the old dhrystone benchmark; the entire build takes 17:51 minutes:seconds walltime, 28:11 cputime. (it is dominated by lisp-execution and library compiles). A ca 1970 machine would be on the order of 10000 times slower, and this would take around 200 days, much more than the MTBF of those machines. And this is just building one of the important subsystems of todays Linux world. Actually coping with the amount of code we have today wouldn't be feasible much before 1995'ish in terms of cpu resources. Not to mention the actual cpus needed to execute it. -- mrr
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2015-07-23 15:37 -0700 |
| Message-ID | <j4r2ra5uae61uak7gu3mc9b3n6ll7g6292@4ax.com> |
| In reply to | #148810 |
On Wed, 22 Jul 2015 19:37:59 +0200, Morten Reistad
<first@last.name.invalid> wrote:
[snip]
>Building emacs on my display computer, a 4-core arm7 with SSD and 4x1.7Ghz
>cpus each measuring just short of 4 bips with the old dhrystone benchmark;
>the entire build takes 17:51 minutes:seconds walltime, 28:11 cputime.
>(it is dominated by lisp-execution and library compiles). A ca 1970
>machine would be on the order of 10000 times slower, and this would
>take around 200 days, much more than the MTBF of those machines.
Huh? More walltime than CPU time? How does that work?
[snip]
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name.invalid> |
|---|---|
| Date | 2015-07-24 01:17 +0200 |
| Message-ID | <09988c-0tn.ln1@sambook.reistad.name> |
| In reply to | #148891 |
In article <j4r2ra5uae61uak7gu3mc9b3n6ll7g6292@4ax.com>, Gene Wirchenko <genew@telus.net> wrote: >On Wed, 22 Jul 2015 19:37:59 +0200, Morten Reistad ><first@last.name.invalid> wrote: > >[snip] > >>Building emacs on my display computer, a 4-core arm7 with SSD and 4x1.7Ghz >>cpus each measuring just short of 4 bips with the old dhrystone benchmark; >>the entire build takes 17:51 minutes:seconds walltime, 28:11 cputime. >>(it is dominated by lisp-execution and library compiles). A ca 1970 >>machine would be on the order of 10000 times slower, and this would >>take around 200 days, much more than the MTBF of those machines. > > Huh? More walltime than CPU time? How does that work? > >[snip] No, 17:51 < 28:11. Now, if you meant the opposite question; the CPUtime is larger because there are multiple cpus. I did a "make -j 5", starting up to 5 parallel sub-jobs on a 4-processor machine. When it farmed out for real the system went partially I/O-bound, which is rare for such a big compile job. Emacs has way too many internal single-file dependencies for that to happen for more than 2-3 minutes of the total time, though. -- mrr
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2015-07-24 11:12 -0700 |
| Message-ID | <htv4ra1uvg893jn4h2bg40v6f0vna206vm@4ax.com> |
| In reply to | #148892 |
On Fri, 24 Jul 2015 01:17:20 +0200, Morten Reistad
<first@last.name.invalid> wrote:
>In article <j4r2ra5uae61uak7gu3mc9b3n6ll7g6292@4ax.com>,
>Gene Wirchenko <genew@telus.net> wrote:
>>On Wed, 22 Jul 2015 19:37:59 +0200, Morten Reistad
>><first@last.name.invalid> wrote:
>>
>>[snip]
>>
>>>Building emacs on my display computer, a 4-core arm7 with SSD and 4x1.7Ghz
>>>cpus each measuring just short of 4 bips with the old dhrystone benchmark;
>>>the entire build takes 17:51 minutes:seconds walltime, 28:11 cputime.
>>>(it is dominated by lisp-execution and library compiles). A ca 1970
>>>machine would be on the order of 10000 times slower, and this would
>>>take around 200 days, much more than the MTBF of those machines.
>>
>> Huh? More walltime than CPU time? How does that work?
>>
>>[snip]
>
>No, 17:51 < 28:11.
>
>Now, if you meant the opposite question; the CPUtime is larger because
Ouch! I did. Another instance (or instantiation?) of Skitt's
Law?
>there are multiple cpus. I did a "make -j 5", starting up to 5
Ah, I did not think of multiple CPUs. Thank you.
>parallel sub-jobs on a 4-processor machine. When it farmed out for
>real the system went partially I/O-bound, which is rare for such a big
>compile job. Emacs has way too many internal single-file dependencies
>for that to happen for more than 2-3 minutes of the total time, though.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2015-07-24 11:52 +0000 |
| Message-ID | <PM00051B9DAEB914AE@aca40d61.ipt.aol.com> |
| In reply to | #148891 |
Gene Wirchenko wrote: > On Wed, 22 Jul 2015 19:37:59 +0200, Morten Reistad > <first@last.name.invalid> wrote: > > [snip] > >>Building emacs on my display computer, a 4-core arm7 with SSD and 4x1.7Ghz >>cpus each measuring just short of 4 bips with the old dhrystone benchmark; >>the entire build takes 17:51 minutes:seconds walltime, 28:11 cputime. >>(it is dominated by lisp-execution and library compiles). A ca 1970 >>machine would be on the order of 10000 times slower, and this would >>take around 200 days, much more than the MTBF of those machines. > > Huh? More walltime than CPU time? How does that work? If you have 4 CPUs acutally doing stuff, the ideal runtime will be 4 times wall clock time. /BAH
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name> |
|---|---|
| Date | 2015-07-24 18:01 +0200 |
| Message-ID | <944a8c-hnr.ln1@sambook.reistad.name> |
| In reply to | #148902 |
In article <PM00051B9DAEB914AE@aca40d61.ipt.aol.com>, jmfbahciv <See.above@aol.com> wrote: >Gene Wirchenko wrote: >> On Wed, 22 Jul 2015 19:37:59 +0200, Morten Reistad >> <first@last.name.invalid> wrote: >> >> [snip] >> >>>Building emacs on my display computer, a 4-core arm7 with SSD and 4x1.7Ghz >>>cpus each measuring just short of 4 bips with the old dhrystone benchmark; >>>the entire build takes 17:51 minutes:seconds walltime, 28:11 cputime. >>>(it is dominated by lisp-execution and library compiles). A ca 1970 >>>machine would be on the order of 10000 times slower, and this would >>>take around 200 days, much more than the MTBF of those machines. >> >> Huh? More walltime than CPU time? How does that work? > >If you have 4 CPUs acutally doing stuff, the ideal runtime will be >4 times wall clock time. In this case around 2 3/4 cpu were dedicated to the compiler chugging away, around a quarter to the file system, and an entire cpu to the I/O, where it was around 40% in device drivers, 25% in interrupts and the rest waiting for I/O; in practice idle 35% of the time. (but servicing 200+ very scattered I/Os per second. This is with the standard (arm7/armhf) schedulers in Linux. It will be interesting to see what happens when I get the 8-processor SOC next week, if the I/O dedicated CPU gets into overload, or what. The build of emacs consisted of around 4 minutes worth of C-compiling and linking, and 12 minutes of lisp load and partially compile; a process that is not very parallizable, at least from make. Then there were around two minutes of spitting out binaries in the end. I'll try a compile of something a lot mora pure C next time. -- mrr
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2015-07-24 20:41 +0000 |
| Message-ID | <51963309459462168.669344peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #148902 |
jmfbahciv <See.above@aol.com> wrote: > Gene Wirchenko wrote: >> On Wed, 22 Jul 2015 19:37:59 +0200, Morten Reistad >> <first@last.name.invalid> wrote: >> >> [snip] >> >>> Building emacs on my display computer, a 4-core arm7 with SSD and 4x1.7Ghz >>> cpus each measuring just short of 4 bips with the old dhrystone benchmark; >>> the entire build takes 17:51 minutes:seconds walltime, 28:11 cputime. >>> (it is dominated by lisp-execution and library compiles). A ca 1970 >>> machine would be on the order of 10000 times slower, and this would >>> take around 200 days, much more than the MTBF of those machines. >> >> Huh? More walltime than CPU time? How does that work? > > If you have 4 CPUs acutally doing stuff, the ideal runtime will be > 4 times wall clock time. > Huh?? -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2015-07-24 17:06 -0400 |
| Message-ID | <mou9a0$e4m$1@dont-email.me> |
| In reply to | #148944 |
Peter Flass <peter_flass@yahoo.com> writes: > jmfbahciv <See.above@aol.com> wrote: >> Gene Wirchenko wrote: >>> On Wed, 22 Jul 2015 19:37:59 +0200, Morten Reistad >>> <first@last.name.invalid> wrote: >>> >>> [snip] >>> >>>> Building emacs on my display computer, a 4-core arm7 with SSD and 4x1.7Ghz >>>> cpus each measuring just short of 4 bips with the old dhrystone benchmark; >>>> the entire build takes 17:51 minutes:seconds walltime, 28:11 cputime. >>>> (it is dominated by lisp-execution and library compiles). A ca 1970 >>>> machine would be on the order of 10000 times slower, and this would >>>> take around 200 days, much more than the MTBF of those machines. >>> >>> Huh? More walltime than CPU time? How does that work? >> >> If you have 4 CPUs acutally doing stuff, the ideal runtime will be >> 4 times wall clock time. > > Huh?? Pete, all these years and you still think she is capable of making even a little bit of sense? Run time and wall time are, of course, synonyms. No surprise she doesn't even know the terms. Building Emacs, of course involves more than CPU time. Everyone knows that, except you know who. It's not worth asking. You'll see. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2015-07-25 12:42 +0000 |
| Message-ID | <PM00051BB2ACE0E440@aca41464.ipt.aol.com> |
| In reply to | #148944 |
Peter Flass wrote: > jmfbahciv <See.above@aol.com> wrote: >> Gene Wirchenko wrote: >>> On Wed, 22 Jul 2015 19:37:59 +0200, Morten Reistad >>> <first@last.name.invalid> wrote: >>> >>> [snip] >>> >>>> Building emacs on my display computer, a 4-core arm7 with SSD and 4x1.7Ghz >>>> cpus each measuring just short of 4 bips with the old dhrystone benchmark; >>>> the entire build takes 17:51 minutes:seconds walltime, 28:11 cputime. >>>> (it is dominated by lisp-execution and library compiles). A ca 1970 >>>> machine would be on the order of 10000 times slower, and this would >>>> take around 200 days, much more than the MTBF of those machines. >>> >>> Huh? More walltime than CPU time? How does that work? >> >> If you have 4 CPUs acutally doing stuff, the ideal runtime will be >> 4 times wall clock time. >> > > Huh?? > Runtime was an accounting datum we captured for each job. the monitor recorded CPU-seconds which was the CPU runtime used by the job minus the overhead. On a system with 4 CPUs, an ideal total runtime (no overhead) would be 4 times wall clock elapsed time. We also captured a thingie called kilo-core-seconds but that almost became meaningless. Do OSes collect any accounting data now? /BAH
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2015-07-25 14:13 +0000 |
| Message-ID | <1209961220459526106.498043peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #148950 |
jmfbahciv <See.above@aol.com> wrote: > Peter Flass wrote: >> jmfbahciv <See.above@aol.com> wrote: >>> Gene Wirchenko wrote: >>>> On Wed, 22 Jul 2015 19:37:59 +0200, Morten Reistad >>>> <first@last.name.invalid> wrote: >>>> >>>> [snip] >>>> >>>>> Building emacs on my display computer, a 4-core arm7 with SSD and > 4x1.7Ghz >>>>> cpus each measuring just short of 4 bips with the old dhrystone > benchmark; >>>>> the entire build takes 17:51 minutes:seconds walltime, 28:11 cputime. >>>>> (it is dominated by lisp-execution and library compiles). A ca 1970 >>>>> machine would be on the order of 10000 times slower, and this would >>>>> take around 200 days, much more than the MTBF of those machines. >>>> >>>> Huh? More walltime than CPU time? How does that work? >>> >>> If you have 4 CPUs acutally doing stuff, the ideal runtime will be >>> 4 times wall clock time. >>> >> >> Huh?? >> > Runtime was an accounting datum we captured for each job. the monitor > recorded CPU-seconds which was the CPU runtime used by the job minus > the overhead. On a system with 4 CPUs, an ideal total runtime (no overhead) > would be 4 times wall clock elapsed time. > > We also captured a thingie called kilo-core-seconds but that almost > became meaningless. Do OSes collect any accounting data now? > God yes. PPOE used to stack a month's worth of data on a 3590 cartridge (60GB), down from several 3480's/month. It took forever when we had to extract data to produce a special report. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | lawrence@cluon.com |
|---|---|
| Date | 2015-07-27 03:00 +0200 |
| Message-ID | <87si8ao1mw.fsf@cluon.com> |
| In reply to | #148951 |
Peter Flass <peter_flass@yahoo.com> writes: > [much deletia about CPU time] > God yes. PPOE used to stack a month's worth of data on a 3590 cartridge > (60GB), down from several 3480's/month. It took forever when we had to > extract data to produce a special report. What was the overall nature of the report, who wanted to see it, and does it have any measurable EFFECT in how the company operates? Are any decisions made because this class of programs used 'more CPU seconds than they should have?'??
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2015-07-27 14:08 +0000 |
| Message-ID | <73598083459698259.869030peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #148961 |
<lawrence@cluon.com> wrote: > Peter Flass <peter_flass@yahoo.com> writes: >> [much deletia about CPU time] >> God yes. PPOE used to stack a month's worth of data on a 3590 cartridge >> (60GB), down from several 3480's/month. It took forever when we had to >> extract data to produce a special report. > > What was the overall nature of the report, who wanted to see it, and > does it have any measurable EFFECT in how the company operates? Are any > decisions made because this class of programs used 'more CPU seconds > than they should have?'?? Sometimes the data was used to provide justification for an upgrade. What really ballooned up the size was adding all the CICS transaction data. I think out CICS guy used that for something, but I don't know what . -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2015-07-27 08:43 -0700 |
| Message-ID | <87egjt38tc.fsf@lhwserver.localdomain> |
| In reply to | #148968 |
Peter Flass <peter_flass@yahoo.com> writes: > Sometimes the data was used to provide justification for an upgrade. What > really ballooned up the size was adding all the CICS transaction data. I > think out CICS guy used that for something, but I don't know what . MVS measured waittime to infer total cpu time (elapsed minus waittime). application cpu use was somewhat approximate ... and then there was "capture ratio" ... aka accounted for cpu divided by total cpu (which was elapsed minus wait). unaccounted for time could range from 20% to 80%. VTAM (terminal i/o) could really drive down "capture ratio" I've talked before about internal installations looking at deploying loads of 4341s out into departmental areas ... primarily because large datacenters were exploding at the seams and difficulty in adding more computing capacity ... but in part because they could (4341 significantly improved computing price/performance ... and significantly reduced the space and environmental footprint). One of the issues was moving MVS-based applications to 4341 (MVS required significant human resources for its care and feeding, couldn't have several dedicated staff in every department) ... the simpler applications could be directly moved to vm/cms ... the more complex ones required enhancements to the MVS simulation in CMS. The other benefit was that the significant MVS&VTAM processing overhead was eliminated (uncaptured CPU) ... further improving the processing efficiency. old email mentioning 4341 http://www.garlic.com/~lynn/lhwemail.html#4341 past posts mentioning capture ratio http://www.garlic.com/~lynn/2005m.html#16 CPU time and system load http://www.garlic.com/~lynn/2006v.html#19 Ranking of non-IBM mainframe builders? http://www.garlic.com/~lynn/2007g.html#82 IBM to the PCM market http://www.garlic.com/~lynn/2007t.html#23 SMF Under VM http://www.garlic.com/~lynn/2008.html#42 Inaccurate CPU% reported by RMF and TMON http://www.garlic.com/~lynn/2008d.html#72 Price of CPU seconds http://www.garlic.com/~lynn/2010d.html#66 LPARs: More or Less? http://www.garlic.com/~lynn/2010e.html#33 SHAREWARE at Its Finest http://www.garlic.com/~lynn/2010e.html#76 LPARs: More or Less? http://www.garlic.com/~lynn/2010m.html#39 CPU time variance http://www.garlic.com/~lynn/2012h.html#70 How many cost a cpu second? http://www.garlic.com/~lynn/2012j.html#71 Help with elementary CPU speed question http://www.garlic.com/~lynn/2013d.html#8 What Makes an Architecture Bizarre? http://www.garlic.com/~lynn/2013d.html#14 What Makes an Architecture Bizarre? http://www.garlic.com/~lynn/2014b.html#78 CPU time http://www.garlic.com/~lynn/2014b.html#80 CPU time http://www.garlic.com/~lynn/2014b.html#82 CPU time http://www.garlic.com/~lynn/2014b.html#85 CPU time -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2015-07-27 13:56 -0700 |
| Message-ID | <877fpl2uc5.fsf@lhwserver.localdomain> |
| In reply to | #148980 |
re: http://www.garlic.com/~lynn/2015f.html#68 1973--TI 8 digit electric calculator--$99.95 60s, science center did extensive work on cp40 and then cp67 to gather accurate statistics and use them for resource management and scheduling (and accounting) http://www.garlic.com/~lynn/subtopic.html#545tech however, cp67 delivered to univ. jan1968 took enormous amount of processing to support the accurate statistics, resource management and scheduling. Even after the Lincoln Labs redo shipped later spring of 1968 ... 35users could still take 10% of processing (overhead increased non-linear with number of users). Then as undergraudate in the 60s, I then redid the whole thing, making the overhead linear proportional to user activity (independent of number of users) and drastically reducing to less than 1% of user activity ... while making the resource management and scheduling much more effective. This was shipped to customers and came to be referred to as "wheeler scheduler" or "fair share scheduler" (because default resource management policy was fair share). http://www.garlic.com/~lynn/subtopic.html#fairshare In the early 70s, the science center used the extensive statistics gathering for modeling (both analytical and event driven) as configuration and workload profiling (which evolved into capacity planning). A variation on one of the (science center, APL-based) analytical models was made available on the world-wide sales & marketing online HONE systems as the Performance Predictor; SEs could enter customer configuration and workload profiles and ask "what-if" questions about what happens when configuration and/or workload changes are made. http://www.garlic.com/~lynn/subtopic.html#hone -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web