comp.lang.ada
 help / color / mirror / Atom feed
From: "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>
Subject: Re: [OT] Gibson's vision of computer languajes
Date: Wed, 6 Mar 2002 09:27:50 -0500
Date: 2002-03-06T14:27:51+00:00	[thread overview]
Message-ID: <a65917$p68$1@nh.pace.co.uk> (raw)
In-Reply-To: a63js4$9qe1@news.cis.okstate.edu


"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:a63js4$9qe1@news.cis.okstate.edu...
>
> "Best suited language" implies that running speed is the goal. It's
> frequently not, and sometimes where it is, assembly just isn't going to
> make enough difference. I have a couple programs that need to be sped
> up. 3 orders of magnitude should get them fast enough that I can
> actually get results sometime. I may be able to make one faster - but
> only if I can reason about it easily, which assembly doesn't help. The
> primary goal for a lot of scientists is getting a correct answer in a
> reasonable amount of time, with minimal programming knowledge.
> Assembly's not the tool for that job, either.
>

Many compilers are capable of producing code that is as tight - or nearly as
tight - as a skilled assembly programmer could do. (Given the same semantic
requirements, of course. No fair requiring runtime checks of the compiler
and not from the assembly expert...) And while with one given small segment
of code, the assembly programmer might just be able to beat the compiler, I
have faith that the compiler will do a consistently better job across the
whole body of code more often than the programmer.

So if speed is the only advantage, I'd contend that for reasonably large
programs, you won't find any significant improvements to doing the whole
thing in assembler versus doing it in a high level language. Clearly, one
might hand-optimize the small percentage of the code doing the really hard
work & buy an improvement, but it isn't going to change things much to do
the whole job in assembler. Machines work consistently better at producing
high quality stuff than do humans. A skilled human with a file and a raw
chunk of steel might produce a really fine automobile engine one day. But
stamping them out with CNC machinery is likely to produce a lot more of them
at a consistently higher quality.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/





  reply	other threads:[~2002-03-06 14:27 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-04 22:17 [OT] Gibson's vision of computer languajes Jano
2002-03-04 23:38 ` Dave Poirier
2002-03-05 17:03   ` Pascal Obry
2002-03-05 17:43     ` Dave Poirier
2002-03-05 18:29       ` Marin David Condic
2002-03-06  5:35         ` Dave Poirier
2002-03-06 10:25           ` John English
2002-03-06 14:48             ` Marin David Condic
2002-03-06 14:46           ` Marin David Condic
2002-03-06 17:13           ` Wes Groleau
2002-03-06 17:29           ` Warren W. Gay VE3WWG
2002-03-06 18:27             ` Marin David Condic
2002-03-05 23:20       ` David Starner
2002-03-06 14:27         ` Marin David Condic [this message]
2002-03-05 17:24   ` Warren W. Gay VE3WWG
2002-03-05 17:53     ` Dave Poirier
2002-03-05 19:33     ` Darren New
2002-03-04 23:47 ` [OT] Gibson's vision of computer languages Larry Kilgallen
2002-03-05  1:43   ` Richard Riehle
2002-03-05 17:25   ` Warren W. Gay VE3WWG
2002-03-05 21:20     ` Larry Kilgallen
2002-03-05 21:43     ` Wes Groleau
2002-03-05 21:31   ` Wes Groleau
2002-03-04 23:49 ` [OT] Gibson's vision of computer languajes Darren New
2002-03-04 23:59 ` Al Mole
2002-03-05  1:38 ` tmoran
2002-03-05  8:58   ` Thomas Koenig
2002-03-05  2:18 ` Adrian Hoe
2002-03-05  3:12 ` Chad R. Meiners
2002-03-05 15:24 ` Preben Randhol
2002-03-05 18:08 ` chris.danx
2002-03-05 21:35   ` sk
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox