Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #9626 > unrolled thread
| Started by | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| First post | 2019-02-24 12:40 +0800 |
| Last post | 2019-02-25 19:04 +0800 |
| Articles | 20 on this page of 180 — 32 participants |
Back to article view | Back to comp.programming
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: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 12:40 +0800
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 05:16 +0000
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 13:20 +0800
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 13:24 +0800
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 19:45 +0800
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 13:09 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 14:38 +0000
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 15:18 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 17:21 +0100
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 17:43 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 20:17 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:19 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 20:02 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 19:26 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 21:36 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 20:47 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:10 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:25 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 12:24 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 17:04 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 16:52 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 17:59 -0800
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 08:46 +0100
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 09:36 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 10:13 +0100
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-26 09:56 +0100
Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-25 14:12 +0000
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 12:20 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 13:36 -0800
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:29 +0200
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 09:41 +0100
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:55 +0200
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 10:24 +0100
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:03 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:58 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 09:40 +0100
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 10:01 +0100
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 12:55 -0800
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:31 +0100
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 17:42 +0000
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:19 +0000
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-24 17:56 +0000
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:23 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 20:58 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 20:52 +0000
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-25 16:31 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 14:01 -0800
Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-25 23:04 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 15:53 -0800
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:07 +0000
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 20:50 +0100
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:04 +0000
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-28 16:25 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-28 11:56 -0500
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-28 19:45 +0000
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 17:55 +0000
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:03 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-28 11:25 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-28 19:30 +0000
Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-24 20:47 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:29 +0000
Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-25 20:16 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 12:53 -0800
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 09:49 +0200
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 21:07 +0100
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 22:59 +0000
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-26 09:57 +0100
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 09:59 +0000
Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-02-24 19:54 +1300
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 07:56 +0000
Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-02-24 21:58 +1300
Re: C is not a low level language "A. Dumas" <alexandre@dumas.fr.invalid> - 2019-02-24 10:57 +0100
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 10:13 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 10:47 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 08:48 -0500
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 14:42 +0000
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 07:15 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 09:25 -0500
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 15:03 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 12:10 -0500
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 17:58 +0000
Re: C is not a low level language Axel Berger <Spam@Berger-Odenthal.De> - 2019-02-25 17:44 +0100
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 19:18 +0200
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:35 +0200
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 10:44 +0000
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 12:29 +0000
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 14:26 +0000
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 17:08 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:08 +0200
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 18:00 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-27 22:37 -0800
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-28 02:25 -0800
Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 12:27 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 09:36 -0500
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 15:05 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 19:20 +0200
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 23:02 +0000
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 06:52 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:41 +0200
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 12:20 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 14:01 +0100
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-26 08:48 -0500
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-26 19:20 +0100
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 10:04 -0500
Re: C is not a low level language lonelydad <lonelydad58@gmail.com> - 2019-02-24 14:44 +0000
Re: C is not a low level language "U-laptop\\Norah" <Norah@laptop.i-did-not-set--mail-host-address--so-tickle-me> - 2019-02-27 16:16 -0600
Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-03-01 12:12 +1300
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-03-01 00:19 +0000
Re: C is not a low level language Gene Wirchenko <genew@telus.net> - 2019-02-24 19:59 -0800
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-25 16:10 +0000
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 21:02 +0100
Re: C is not a low level language Lars Enderin <lars.enderin@telia.com> - 2019-02-26 00:37 +0100
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 19:09 -0500
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 06:52 +0000
Re: C is not a low level language T <T@invalid.invalid> - 2019-02-24 00:30 -0800
Re: C is not a low level language T <T@invalid.invalid> - 2019-02-24 00:31 -0800
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 10:16 +0000
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-24 11:22 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 08:51 -0500
Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 07:20 -0800
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-24 15:35 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 11:05 -0500
Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 14:39 -0800
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 19:11 -0800
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 09:41 -0500
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 14:53 +0000
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 10:19 -0500
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-25 16:38 +0100
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 11:20 -0500
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 17:49 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:18 +0100
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:25 +0200
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:40 -0500
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:45 +0200
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-26 08:02 -0500
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-26 09:11 -0500
Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:23 +0100
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-26 08:02 -0500
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 17:57 +0200
Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 17:42 -0500
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 22:33 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:30 +0100
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 13:52 -0800
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 15:20 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 18:47 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:50 -0500
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 18:59 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:15 +0200
Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-25 18:38 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:49 +0200
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:40 -0500
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:55 +0200
Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-26 16:29 +0000
Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-03-04 23:43 -0500
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 18:16 +0000
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 17:44 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:05 -0500
Re: C is not a low level language Robert Wessel <robertwessel2@yahoo.com> - 2019-02-26 00:51 -0600
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 10:58 +0100
Re: C is not a low level language Robert Wessel <robertwessel2@yahoo.com> - 2019-02-26 10:53 -0600
Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 17:49 +0000
Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-26 18:11 +0000
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-26 18:24 +0000
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 19:24 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 19:44 +0100
Re: C is not a low level language nobody@example.org (Scott) - 2019-02-26 06:33 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
Re: C is not a low level language Gene Wirchenko <genew@telus.net> - 2019-02-24 20:03 -0800
Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 14:56 -0800
Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-24 20:43 +0000
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-25 14:14 +0800
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 10:45 +0000
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-25 19:04 +0800
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-26 08:02 -0500 |
| Message-ID | <260220190802233653%nospam@nospam.invalid> |
| In reply to | #9769 |
In article <q52t2e$vqb$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: > >> There are almost no programming fields that require hand-written > >> assembly these days. Even if you are writing a compiler, or low-level > >> libraries for a compiler, you are unlikely to need more than small > >> sections or snippets of assembly. There are still occasions where > >> assembly will give you noticeably more efficient results than a > >> high-level language - but very, very few where the difference is big > >> enough to warrant using assembly. Generally, if you think assembly is > >> the best choice then you have picked an inappropriate processor, > >> inappropriate tools, or an inappropriate programmer. > > > > exactly > > > >> I think it is good for programmers to have some experience of assembly, > >> and to have understanding of it - it helps give a better appreciation of > >> how things work underneath, and can lead to the programmer writing > >> better high-level code (especially on smaller systems). But that is > >> different from actually writing assembly for real work. > > > > what matters the most are good algorithms, and knowing assembly does > > not help with that. > > > > That is often the case - but certainly not always. Good algorithms are > important when "n" is big - but "n" is usually small. For a small > enough size, bubblesort will beat heapsort. Good algorithms are not to > be underestimated - but not overestimated either. > > And knowing assembly can give better algorithm implementations, simply > because the programmer is more aware of the underlying hardware. It can > help when you are trying to decide if you should be fiddling with > objects, or pointers to objects, for example. false.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-02-26 17:57 +0200 |
| Message-ID | <594gkf-rsn.ln1@gangtai.home.grep.be> |
| In reply to | #9780 |
On 26/02/2019 15:02, nospam wrote: > In article <q52t2e$vqb$1@dont-email.me>, David Brown > <david.brown@hesbynett.no> wrote: > >>>> There are almost no programming fields that require hand-written >>>> assembly these days. Even if you are writing a compiler, or low-level >>>> libraries for a compiler, you are unlikely to need more than small >>>> sections or snippets of assembly. There are still occasions where >>>> assembly will give you noticeably more efficient results than a >>>> high-level language - but very, very few where the difference is big >>>> enough to warrant using assembly. Generally, if you think assembly is >>>> the best choice then you have picked an inappropriate processor, >>>> inappropriate tools, or an inappropriate programmer. >>> >>> exactly >>> >>>> I think it is good for programmers to have some experience of assembly, >>>> and to have understanding of it - it helps give a better appreciation of >>>> how things work underneath, and can lead to the programmer writing >>>> better high-level code (especially on smaller systems). But that is >>>> different from actually writing assembly for real work. >>> >>> what matters the most are good algorithms, and knowing assembly does >>> not help with that. >>> >> >> That is often the case - but certainly not always. Good algorithms are >> important when "n" is big - but "n" is usually small. For a small >> enough size, bubblesort will beat heapsort. Good algorithms are not to >> be underestimated - but not overestimated either. >> >> And knowing assembly can give better algorithm implementations, simply >> because the programmer is more aware of the underlying hardware. It can >> help when you are trying to decide if you should be fiddling with >> objects, or pointers to objects, for example. > > false. > Now that was a well-written argument. Well done! (plonk)
[toc] | [prev] | [next] | [standalone]
| From | Diesel <nobody@haph.org> |
|---|---|
| Date | 2019-03-05 04:29 +0000 |
| Message-ID | <XnsAA08EFC7B99DEHT1@doCX0.74.zmu4y91> |
| In reply to | #9728 |
nospam <nospam@nospam.invalid> news:250220191217497304%nospam@nospam.invalid Mon, 25 Feb 2019 17:17:49 GMT in alt.windows7.general, wrote: >> I think it is good for programmers to have some experience of >> assembly, and to have understanding of it - it helps give a >> better appreciation of how things work underneath, and can lead >> to the programmer writing better high-level code (especially on >> smaller systems). But that is different from actually writing >> assembly for real work. > > what matters the most are good algorithms, and knowing assembly > does not help with that. IMO, I believe it does. -- Friends help you move. Real friends help you move bodies.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-25 17:42 -0500 |
| Message-ID | <250220191742376649%nospam@nospam.invalid> |
| In reply to | #9717 |
In article <T2_cE.1672$Dv1.95@fx05.am4>, Bart <bc@freeuk.com> wrote: > > There are almost no programming fields that require hand-written > > assembly these days. Even if you are writing a compiler, or low-level > > libraries for a compiler, you are unlikely to need more than small > > sections or snippets of assembly. There are still occasions where > > assembly will give you noticeably more efficient results than a > > high-level language - but very, very few where the difference is big > > enough to warrant using assembly. Generally, if you think assembly is > > the best choice then you have picked an inappropriate processor, > > inappropriate tools, or an inappropriate programmer. > > The sorts of arguments can be made against using C or C++. With 90% of > the code of an application, probably it doesn't matter how efficient a > language or compiler is, because the bottlenecks are in the 10%. more like 1%
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-25 22:33 +0000 |
| Message-ID | <T2_cE.1672$Dv1.95@fx05.am4> |
| In reply to | #9717 |
On 25/02/2019 15:38, David Brown wrote: > There are almost no programming fields that require hand-written > assembly these days. Even if you are writing a compiler, or low-level > libraries for a compiler, you are unlikely to need more than small > sections or snippets of assembly. There are still occasions where > assembly will give you noticeably more efficient results than a > high-level language - but very, very few where the difference is big > enough to warrant using assembly. Generally, if you think assembly is > the best choice then you have picked an inappropriate processor, > inappropriate tools, or an inappropriate programmer. The sorts of arguments can be made against using C or C++. With 90% of the code of an application, probably it doesn't matter how efficient a language or compiler is, because the bottlenecks are in the 10%.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-26 09:30 +0100 |
| Message-ID | <q52tfk$2gb$1@dont-email.me> |
| In reply to | #9755 |
On 25/02/2019 23:33, Bart wrote: > On 25/02/2019 15:38, David Brown wrote: > >> There are almost no programming fields that require hand-written >> assembly these days. Even if you are writing a compiler, or low-level >> libraries for a compiler, you are unlikely to need more than small >> sections or snippets of assembly. There are still occasions where >> assembly will give you noticeably more efficient results than a >> high-level language - but very, very few where the difference is big >> enough to warrant using assembly. Generally, if you think assembly is >> the best choice then you have picked an inappropriate processor, >> inappropriate tools, or an inappropriate programmer. > > The sorts of arguments can be made against using C or C++. With 90% of > the code of an application, probably it doesn't matter how efficient a > language or compiler is, because the bottlenecks are in the 10%. Agreed. For a lot of programming, C is a poor choice of language (better than assembly, but still not good). C++ is a different matter - it spans low-level and high-level coding, and thus covers a far wider range of applications. But often a high-level language such as Python makes it much easier to write safe and clear code - and correctness beats run-time efficiency every time.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-25 12:17 -0500 |
| Message-ID | <250220191217487233%nospam@nospam.invalid> |
| In reply to | #9712 |
In article <6ITcE.119027$G52.102800@fx39.iad>, Wolf K <wolfmac@sympatico.ca> wrote: > > About ten years ago, I was startled, speaking to a new graduate with a > > computing degree, when he revealed that he'd NEVER DONE ANY ASSEMBLER. > > Thinking about it afterwards, I decided that the computing world is > > certainly big enough that he'd have no difficulty in finding employment, > > but it did throw me at the time; I'd come up through (7-bit serial then) > > 8-bit, 6800 and 6502, then in professional life some work in bit-slice > > processors (AMD 2901, 2960, etc., and the IDT copies thereof), where we > > had to _create_ our assembly tools as we assembled our processors. > > > > Maybe nowadays assembler is _rare_? > > I think human-created assembler is becoming rare. it is indeed. machine created assembly is almost always better than anything humans can do, plus developers do not want to be tied to a single processor. > However, I have the > impression that robotics requires machine-coded assembler, translated > from whatever human-readable language was used to program the machine. > Those neat videos of dog=like robots loping through the building are > misleading. Their abilities are not only severely limited, but those > abilities were programmed on large machines cabled to the robot. The > programs were tweaked and compressed before being copied to the on-board > chips that control the "dog". where did you get that impression? that is wrong on multiple levels. > Maybe someone from MIT or Boston Dynamics can clarify and correct. maybe.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-25 13:52 -0800 |
| Message-ID | <lnr2bvo7sk.fsf@kst-u.example.com> |
| In reply to | #9712 |
Wolf K <wolfmac@sympatico.ca> writes:
[...]
> I think human-created assembler is becoming rare. However, I have the
> impression that robotics requires machine-coded assembler, translated
> from whatever human-readable language was used to program the machine.
That's true of compiled languages in general, and is not specific to
robotics.
Most compiled languages are translated to assembly language
(or directly to machine language, depending on how the compiler
is designed). (Some, such as Java, are compiled to some kind of
byte code which is then interpreted, but Java can also be compiled
to assembly or machine code.)
[...]
[Followups to comp.programming, which is the only one of the
cross-posted newsgroups that seems appropriate.]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "NY" <me@privacy.net> |
|---|---|
| Date | 2019-02-25 15:20 +0000 |
| Message-ID | <zoidnfqlAvoHmunBnZ2dnUU78L3NnZ2d@brightview.co.uk> |
| In reply to | #9710 |
"J. P. Gilliver (John)" <G6JPG-255@255soft.uk> wrote in message news:+BH$Xu6fFAdcFwF7@255soft.uk... > In message <j8TcE.148893$c46.43996@fx07.iad>, Wolf K > <wolfmac@sympatico.ca> writes: > [] >>FTR, I took an IBM assembler about 40 years ago. Can still read maybe 20% >>of an assembler printout, but couldn't code my way out of paper bag. But >>by the end of the course, I could write 15-20 lines without a bug. The >>instructor said this was pretty good. >> > About ten years ago, I was startled, speaking to a new graduate with a > computing degree, when he revealed that he'd NEVER DONE ANY ASSEMBLER. > Thinking about it afterwards, I decided that the computing world is > certainly big enough that he'd have no difficulty in finding employment, > but it did throw me at the time; I'd come up through (7-bit serial then) > 8-bit, 6800 and 6502, then in professional life some work in bit-slice > processors (AMD 2901, 2960, etc., and the IDT copies thereof), where we > had to _create_ our assembly tools as we assembled our processors. > > Maybe nowadays assembler is _rare_? When I was at university, doing electronic engineering, in the early 1980s, we did a bit of assembler programming, in 6809. Everyone was very frustrated at the choice of CPU because those who had their own computer had either a CP/M-based (Z80) or Commodore Pet (6502); no-one had a computer that used a 6809 that they could practice on out of hours. Of course, a few years later, 8086 and its successors (386, 486 etc) would have been fairly universal ;-) Nowadays they'd probably also teach RISC (eg SPARC and ARM) processors. I remember as a project we had to write software which allowed serial data to be written to a tape and to be read from it, and I don't think anyone go their equipment working: as a project it was a bit too advanced for the amount of practical time allocated to it. I *think* the high-level language we were taught was Pascal. Certainly we didn't learn C because I remember having to learn that from scratch when I started my first job. As a little exercise I managed to code a bubble sort in Z80 on my Wren CP/M 3 computer in the mid 80s. I wrote a BASIC program which allowed a user to enter intergers into an array, then passed the address of that array to a Z80 sort routine and then returned control to the BASIC program to print it out. Developing it was fairly thankless because any mistake in the Z80 crashed the computer, requiring it to be rebooted (from floppy). But I got it working. I forget the actual timings, but I know that the Z80 routine was several orders of magnitude faster than the same algorithm in interpreted BASIC and several times faster than a compiled Pascal program with the same algorithm. I would imagine that the ability to write assembler for any given CPU is nowadays fairly specialised and only done for specific routines that need the absolute maximum speed.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-25 12:17 -0500 |
| Message-ID | <250220191217517376%nospam@nospam.invalid> |
| In reply to | #9713 |
In article <zoidnfqlAvoHmunBnZ2dnUU78L3NnZ2d@brightview.co.uk>, NY <me@privacy.net> wrote: > When I was at university, doing electronic engineering, in the early 1980s, > we did a bit of assembler programming, in 6809. Everyone was very frustrated > at the choice of CPU because those who had their own computer had either a > CP/M-based (Z80) or Commodore Pet (6502); no-one had a computer that used a > 6809 that they could practice on out of hours. Of course, a few years later, > 8086 and its successors (386, 486 etc) would have been fairly universal ;-) > Nowadays they'd probably also teach RISC (eg SPARC and ARM) processors. their frustration was unfamiliarity and inability to learn new things. the 6809 was a *very* good processor, along with its successor, the 68000 series,*far* easier to write code than the z80 and x86. > I remember as a project we had to write software which allowed serial data > to be written to a tape and to be read from it, and I don't think anyone go > their equipment working: as a project it was a bit too advanced for the > amount of practical time allocated to it. > > I *think* the high-level language we were taught was Pascal. Certainly we > didn't learn C because I remember having to learn that from scratch when I > started my first job. pascal was designed to be taught, but ended up being used for much, much more than that. > As a little exercise I managed to code a bubble sort in Z80 on my Wren CP/M > 3 computer in the mid 80s. I wrote a BASIC program which allowed a user to > enter intergers into an array, then passed the address of that array to a > Z80 sort routine and then returned control to the BASIC program to print it > out. Developing it was fairly thankless because any mistake in the Z80 > crashed the computer, requiring it to be rebooted (from floppy). But I got > it working. I forget the actual timings, but I know that the Z80 routine was > several orders of magnitude faster than the same algorithm in interpreted > BASIC and several times faster than a compiled Pascal program with the same > algorithm. that just means the compiler wasn't any good. > I would imagine that the ability to write assembler for any given CPU is > nowadays fairly specialised and only done for specific routines that need > the absolute maximum speed. yep, and it's *really* hard to beat a modern compiler.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-25 18:47 +0000 |
| Message-ID | <OKWcE.4572$jw5.3521@fx25.am4> |
| In reply to | #9729 |
On 25/02/2019 17:17, nospam wrote: > In article <zoidnfqlAvoHmunBnZ2dnUU78L3NnZ2d@brightview.co.uk>, NY > <me@privacy.net> wrote: >> As a little exercise I managed to code a bubble sort in Z80 on my Wren CP/M >> 3 computer in the mid 80s. I wrote a BASIC program which allowed a user to >> enter intergers into an array, then passed the address of that array to a >> Z80 sort routine and then returned control to the BASIC program to print it >> out. Developing it was fairly thankless because any mistake in the Z80 >> crashed the computer, requiring it to be rebooted (from floppy). But I got >> it working. I forget the actual timings, but I know that the Z80 routine was >> several orders of magnitude faster than the same algorithm in interpreted >> BASIC and several times faster than a compiled Pascal program with the same >> algorithm. > > that just means the compiler wasn't any good. 'Several times faster than compiled' sounds about par for the time. >> I would imagine that the ability to write assembler for any given CPU is >> nowadays fairly specialised and only done for specific routines that need >> the absolute maximum speed. > > yep, and it's *really* hard to beat a modern compiler. When writing my interpreters I can routinely get double the performance of gcc-O3, using a non-optimising compiler for 90% of the code coupled with in-line assembly for the main byte-code handlers. In this case it works through having knowledge of the big picture, not available to gcc, and using that to maintain a tight register-based ASM environment.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-25 13:50 -0500 |
| Message-ID | <250220191350140024%nospam@nospam.invalid> |
| In reply to | #9730 |
In article <OKWcE.4572$jw5.3521@fx25.am4>, Bart <bc@freeuk.com> wrote: > >> I would imagine that the ability to write assembler for any given CPU is > >> nowadays fairly specialised and only done for specific routines that need > >> the absolute maximum speed. > > > > yep, and it's *really* hard to beat a modern compiler. > > When writing my interpreters I can routinely get double the performance > of gcc-O3, using a non-optimising compiler for 90% of the code coupled > with in-line assembly for the main byte-code handlers. > > In this case it works through having knowledge of the big picture, not > available to gcc, and using that to maintain a tight register-based ASM > environment. gcc is not an example of a modern compiler. pretty much anything is faster, it's that bad.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-25 18:59 +0000 |
| Message-ID | <jWWcE.1315$ON.1014@fx38.am4> |
| In reply to | #9751 |
On 25/02/2019 18:50, nospam wrote: > In article <OKWcE.4572$jw5.3521@fx25.am4>, Bart <bc@freeuk.com> wrote: > >>>> I would imagine that the ability to write assembler for any given CPU is >>>> nowadays fairly specialised and only done for specific routines that need >>>> the absolute maximum speed. >>> >>> yep, and it's *really* hard to beat a modern compiler. >> >> When writing my interpreters I can routinely get double the performance >> of gcc-O3, using a non-optimising compiler for 90% of the code coupled >> with in-line assembly for the main byte-code handlers. >> >> In this case it works through having knowledge of the big picture, not >> available to gcc, and using that to maintain a tight register-based ASM >> environment. > > gcc is not an example of a modern compiler. pretty much anything is > faster, it's that bad. I got similar results with clang and MSVC. I don't have access to anything else other than smaller compilers which are much worse. Are there any freely available C compilers that could generate code that is /twice/ as fast as gcc-O3 (for the app in my example)? (The performance of gcc in this case can be probably be tweaked by messing around with specialist options, adding attributes, selectively inlining etc, but then you end up spending as much effort as writing the ASM, and it still would not get anywhere near that speed-up.)
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-02-25 20:15 +0200 |
| Message-ID | <rundkf-l8n.ln1@gangtai.home.grep.be> |
| In reply to | #9729 |
On 25/02/2019 20:05, nospam wrote: > code that is not called can't slow anything down. That's actually not true. Code that is not called but is compiled in will use up space in a memory page. If that means the code segment of the program grows beyond a page boundary, that may then mean an extra page fault will need to be handled when part of the program is swapped out, which would otherwise not be necessary. Also, code that is not called but is compiled in may confuse the speculative execution bits of modern microarchitectures into believing the code will do something when it cannot possibly do so. I remember a blog post (can't find it now) from a guy who wrote about a broken opcode on a particular PowerPC-derived processor which will always cause the processor to lock up. Due to speculative execution, even *including* that opcode in the program, even if it's not ever called, could cause the processor to lock up.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-02-25 18:38 +0000 |
| Message-ID | <tCWcE.24897$Js6.2488@fx16.iad> |
| In reply to | #9734 |
Wouter Verhelst <w@uter.be> writes: >On 25/02/2019 20:05, nospam wrote: >> code that is not called can't slow anything down. > >That's actually not true. > >Code that is not called but is compiled in will use up space in a memory >page. If that means the code segment of the program grows beyond a page >boundary, that may then mean an extra page fault will need to be handled >when part of the program is swapped out, which would otherwise not be >necessary. This is true, but less damaging than the effect on instruction cache footprint, which effect is much larger than the effect on the TLB due to additional pages. > >Also, code that is not called but is compiled in may confuse the >speculative execution bits of modern microarchitectures into believing >the code will do something when it cannot possibly do so. Only to the extent that the code is in the execution path (e.g. a seldom executed 'else' clause), but most compilers will elide uncallable and unreachable code completely from the resutling executable. > >I remember a blog post (can't find it now) from a guy who wrote about a >broken opcode on a particular PowerPC-derived processor which will >always cause the processor to lock up. Due to speculative execution, >even *including* that opcode in the program, even if it's not ever >called, could cause the processor to lock up. Again, it would need to be included in a code path that _could_ have been executed (e.g. on a conditional branch) for speculative execution to have caused any issues. Speculative execution doesn't just pick up random bits of the instruction stream and start executing them.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-02-26 12:49 +0200 |
| Message-ID | <07ifkf-tqb.ln1@gangtai.home.grep.be> |
| In reply to | #9743 |
On 25/02/2019 20:38, Scott Lurndal wrote: > Again, it would need to be included in a code path that _could_ > have been executed (e.g. on a conditional branch) for speculative > execution to have caused any issues. That is true; but the code in question was behind a "this really shouldn't happen, but in case it does, ..." type of test. Speculative execution will still pick that up, and it caused the program in question to crash. The unlikely condition abstract enough that the compiler could not optimize it out, let alone the speculative execution in the processor, but beyond that it was never going to be actually executed. Except speculatively, which caused the crash. I should have been clearer about that. > Speculative execution doesn't > just pick up random bits of the instruction stream and start executing > them. Sure.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-25 13:40 -0500 |
| Message-ID | <250220191340475998%nospam@nospam.invalid> |
| In reply to | #9734 |
In article <rundkf-l8n.ln1@gangtai.home.grep.be>, Wouter Verhelst <w@uter.be> wrote: > > code that is not called can't slow anything down. > > That's actually not true. it is true. what matters is the code that *is* called. > Code that is not called but is compiled in will use up space in a memory > page. If that means the code segment of the program grows beyond a page > boundary, that may then mean an extra page fault will need to be handled > when part of the program is swapped out, which would otherwise not be > necessary. that's more theoretical than anything real. nearly everything is i/o bound, and then there are all the other processes... > Also, code that is not called but is compiled in may confuse the > speculative execution bits of modern microarchitectures into believing > the code will do something when it cannot possibly do so. modern compilers already handle that, and one reason why writing assembly that's better than what a compiler can output is *extremely* difficult. > I remember a blog post (can't find it now) from a guy who wrote about a > broken opcode on a particular PowerPC-derived processor which will > always cause the processor to lock up. Due to speculative execution, > even *including* that opcode in the program, even if it's not ever > called, could cause the processor to lock up. that's called 'a bug'.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-02-26 12:55 +0200 |
| Message-ID | <siifkf-tqb.ln1@gangtai.home.grep.be> |
| In reply to | #9752 |
On 25/02/2019 20:40, nospam wrote: > In article <rundkf-l8n.ln1@gangtai.home.grep.be>, Wouter Verhelst > <w@uter.be> wrote: > >>> code that is not called can't slow anything down. >> >> That's actually not true. > > it is true. what matters is the code that *is* called. You're saying that the code can't slow thing down if it's not called. That's a fairly absolute statement; I just showed you a counter-example, and so did Scott. So your absolute statement is just *wrong*. >> Code that is not called but is compiled in will use up space in a memory >> page. If that means the code segment of the program grows beyond a page >> boundary, that may then mean an extra page fault will need to be handled >> when part of the program is swapped out, which would otherwise not be >> necessary. > > that's more theoretical than anything real. It does happen though, and the more "not called" code you add to a program the larger the chances of this happening. Also, it pollutes the processor cache, as Scott pointed out, which will be more likely. > nearly everything is i/o bound, and then there are all the other > processes... It's precisely the other processes which will cause (part of) your program to get (partially) paged out if it is huge, which will cause your slowdowns.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-02-26 16:29 +0000 |
| Message-ID | <8QddE.167$8k5.40@fx33.iad> |
| In reply to | #9784 |
Wouter Verhelst <w@uter.be> writes: >On 25/02/2019 20:40, nospam wrote: >> In article <rundkf-l8n.ln1@gangtai.home.grep.be>, Wouter Verhelst >> <w@uter.be> wrote: >> >>>> code that is not called can't slow anything down. >>> >>> That's actually not true. >> >> it is true. what matters is the code that *is* called. > >You're saying that the code can't slow thing down if it's not called. >That's a fairly absolute statement; I just showed you a counter-example, >and so did Scott. So your absolute statement is just *wrong*. > >>> Code that is not called but is compiled in will use up space in a memory >>> page. If that means the code segment of the program grows beyond a page >>> boundary, that may then mean an extra page fault will need to be handled >>> when part of the program is swapped out, which would otherwise not be >>> necessary. >> >> that's more theoretical than anything real. > >It does happen though, and the more "not called" code you add to a >program the larger the chances of this happening. Actually it happens more often than you think, which is one reason that execution-driven feedback into code layout is so effective in increasing application performance for certain classes of applications. > >> nearly everything is i/o bound, and then there are all the other >> processes... Not at all true, particularly with respect to the applications where performance matters (HPC, in-memory databases, etc). Windows desktop applications aren't the whole world, you know.
[toc] | [prev] | [next] | [standalone]
| From | Diesel <nobody@haph.org> |
|---|---|
| Date | 2019-03-05 04:29 +0000 |
| Message-ID | <XnsAA08EFC8FEB41HT1@doCX0.74.zmu4y91> |
| In reply to | #9786 |
scott@slp53.sl.home (Scott Lurndal) news:8QddE.167$8k5.40@fx33.iad Tue, 26 Feb 2019 16:29:56 GMT in alt.windows7.general, wrote: > Windows desktop applications aren't the whole world, you know. nospam doesn't, afaik, write windows desktop applications. They write apps for Apple based products. cell phones primarily I believe, in a scripting language. So...I dunno what level of programmer or coder you'd actually consider the individual to be. -- I just reversed the polarity flow.
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.programming
csiph-web