Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #14720 > unrolled thread
| Started by | "Bill Cunningham" <nospam@nspam.invalid> |
|---|---|
| First post | 2011-12-18 20:51 -0500 |
| Last post | 2011-12-19 22:35 +0000 |
| Articles | 20 on this page of 106 — 24 participants |
Back to article view | Back to comp.lang.c
code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-18 20:51 -0500
Re: code snippet Geoff <geoff@invalid.invalid> - 2011-12-18 18:29 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-18 21:51 -0500
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-18 22:24 -0500
Re: code snippet Geoff <geoff@invalid.invalid> - 2011-12-18 19:53 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-18 23:32 -0500
Re: code snippet Geoff <geoff@invalid.invalid> - 2011-12-18 20:57 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-19 00:01 -0500
Re: code snippet Geoff <geoff@invalid.invalid> - 2011-12-18 21:13 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-19 16:42 -0500
Re: code snippet Keith Thompson <kst-u@mib.org> - 2011-12-18 20:14 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-18 23:27 -0500
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-19 12:33 +0000
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-19 16:33 -0500
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-20 00:20 +0000
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-19 19:46 -0500
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-20 01:14 +0000
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-20 15:51 -0500
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-21 14:11 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-21 07:03 -0800
Re: code snippet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-21 21:41 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-21 16:35 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 01:03 +0000
Re: code snippet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-22 03:19 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 07:11 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 16:59 +0000
Re: code snippet "io_x" <a@b.c.invalid> - 2011-12-22 18:38 +0100
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 10:40 -0800
Re: code snippet Markus Wichmann <nullplan@gmx.net> - 2011-12-22 19:12 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 03:50 -0800
Re: code snippet "io_x" <a@b.c.invalid> - 2011-12-28 17:06 +0100
Re: code snippet "io_x" <a@b.c.invalid> - 2012-01-01 20:04 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-01 12:38 -0800
Re: code snippet "io_x" <a@b.c.invalid> - 2012-01-02 10:14 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-03 04:56 -0800
Re: code snippet "io_x" <a@b.c.invalid> - 2012-01-03 18:26 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-04 00:09 -0800
Re: code snippet Ian Collins <ian-news@hotmail.com> - 2012-01-04 21:53 +1300
Re: code snippet "io_x" <a@b.c.invalid> - 2012-01-04 16:14 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-01 12:28 -0800
Re: code snippet "io_x" <a@b.c.invalid> - 2012-01-02 10:18 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-03 04:56 -0800
Re: code snippet "BartC" <bc@freeuk.com> - 2011-12-22 18:05 +0000
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 18:14 +0000
Re: code snippet superpollo <superpollo@tznvy.pbz> - 2011-12-22 20:00 +0100
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 19:08 +0000
Re: code snippet superpollo <superpollo@tznvy.pbz> - 2011-12-22 22:43 +0100
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 21:57 +0000
Re: code snippet BruceS <bruces42@hotmail.com> - 2011-12-23 16:26 -0800
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-22 19:21 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 11:33 -0800
Re: code snippet "io_x" <a@b.c.invalid> - 2011-12-23 09:10 +0100
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-23 14:43 +0000
Re: code snippet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-23 17:14 +0000
Re: code snippet Keith Thompson <kst-u@mib.org> - 2011-12-23 12:10 -0800
Re: code snippet Walter Banks <walter@bytecraft.com> - 2012-01-03 14:24 -0500
Re: code snippet Kaz Kylheku <kaz@kylheku.com> - 2012-01-03 19:58 +0000
Re: code snippet Walter Banks <walter@bytecraft.com> - 2012-01-03 16:15 -0500
Re: code snippet blp@cs.stanford.edu (Ben Pfaff) - 2012-01-03 13:26 -0800
Re: code snippet Kaz Kylheku <kaz@kylheku.com> - 2012-01-03 22:04 +0000
Re: code snippet Ian Collins <ian-news@hotmail.com> - 2012-01-04 15:44 +1300
Re: code snippet "BartC" <bc@freeuk.com> - 2012-01-04 23:34 +0000
Re: code snippet James Harris <james.harris.1@googlemail.com> - 2012-01-04 15:57 -0800
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-05 23:34 -0800
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-06 00:40 -0800
Re: code snippet Kleuske <kleuske@nowhere.net> - 2012-01-06 10:33 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-06 04:30 -0800
Re: code snippet Ian Collins <ian-news@hotmail.com> - 2012-01-04 15:37 +1300
Re: code snippet Kaz Kylheku <kaz@kylheku.com> - 2012-01-04 03:37 +0000
Re: code snippet Ian Collins <ian-news@hotmail.com> - 2012-01-04 20:23 +1300
Re: code snippet jacob navia <jacob@spamsink.net> - 2011-12-22 18:26 +0100
Re: code snippet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-22 19:34 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 11:57 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 20:18 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 12:52 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 20:37 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 13:27 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 21:57 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 14:09 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 21:57 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-23 04:01 -0800
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 14:24 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 21:57 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-01 23:06 -0800
Re: code snippet Hans Vlems <hvlems@freenet.de> - 2011-12-22 23:35 -0800
Re: code snippet "BartC" <bc@freeuk.com> - 2011-12-23 12:26 +0000
Re: code snippet jacob navia <jacob@spamsink.net> - 2011-12-23 18:32 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 04:04 -0800
Re: code snippet "io_x" <a@b.c.invalid> - 2011-12-23 09:10 +0100
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-25 11:13 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-25 19:31 +0000
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-26 21:53 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-26 16:10 -0800
Re: code snippet Keith Thompson <kst-u@mib.org> - 2011-12-26 18:11 -0800
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-26 23:56 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-20 15:57 -0500
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-21 12:39 +0000
Re: code snippet Bill Reid <hormelfree@gmail.com> - 2011-12-22 15:29 -0800
Re: code snippet Geoff <geoff@invalid.invalid> - 2011-12-19 19:19 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-20 13:51 -0500
Re: code snippet Geoff <geoff@invalid.invalid> - 2011-12-20 11:08 -0800
Re: code snippet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-19 11:37 +0000
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-19 16:38 -0500
Re: code snippet "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-12-19 17:02 -0500
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-19 17:21 -0500
Re: code snippet John Gordon <gordon@panix.com> - 2011-12-19 22:35 +0000
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2012-01-02 10:18 +0100 |
| Message-ID | <4f017573$0$1375$4fafbaef@reader2.news.tin.it> |
| In reply to | #15271 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio news:dfd7ae19-4103-4f07-8e9b-c8a7e86f8fc6@q7g2000yqn.googlegroups.com... On Dec 28 2011, 4:06 pm, "io_x" <a...@b.c.invalid> wrote: > #it is pure NASM x86 pentium 32 bits no I meant in a natural languge (english, russian etc.) because the bit I quoted makes no sense. #it is possible because i'm lazy on the speak languages #all you have a good 2012 year...
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-01-03 04:56 -0800 |
| Message-ID | <13b391a9-8523-43ec-8af5-a94e7b3e5a09@v13g2000yqc.googlegroups.com> |
| In reply to | #15305 |
On Jan 2, 9:18 am, "io_x" <a...@b.c.invalid> wrote: > "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:dfd7ae19-4103-4f07-8e9b-c8a7e86f8fc6@q7g2000yqn.googlegroups.com... > On Dec 28 2011, 4:06 pm, "io_x" <a...@b.c.invalid> wrote: > > > #it is pure NASM x86 pentium 32 bits > > no I meant in a natural languge (english, russian etc.) because the > bit I quoted makes no sense. > > #it is possible because i'm lazy on the speak languages > #all you have a good 2012 year... and the same to you
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2011-12-22 18:05 +0000 |
| Message-ID | <jcvrjq$feg$1@dont-email.me> |
| In reply to | #14866 |
"Seebs" <usenet-nospam@seebs.net> wrote in message news:slrnjf6ocv.1rti.usenet-nospam@guild.seebs.net... > On 2011-12-22, 88888 Dihedral <dihedral88888@googlemail.com> wrote: >> Do you consider to convert 5 to 10 lines of C to assembly? > > Of course not. > > 1. It's a great way to introduce errors and bugs. Well, you could say that same about using C! Compared to something higher level, safer, but slower. > 2. It eliminates portability. So what? If this is a product to be sold/used in thousands and millions, you'll probably find that a small number of platforms will dominate. Then it's worth producing a custom version for the top one or two. The rest can use the slow version. If you're distributing the code as binaries, then you will need multiple versions anyway. And if you're distributing as source code, you will have just as many headaches with getting the right combinations of compiler, compiler switches, makefiles and libraries that will work 'out-of-the-box' on anything. > 3. It takes time. > 4. It is very unlikely to produce a measurable benefit. You're assuming this is for a one-off program that will only be run once. Then you could well spend more time programming than will be saved in runtime. But usually that is not the case. > When you're about to pop out to the store, do you take your car's fuel > system apart and rebuild the carburetor? But if you're working in automobile design and production, this is just the sort of thing you might do. Then you end with a version with a very slightly better fuel consumption, but which is significant over a million units and thousands of journeys each. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-12-22 18:14 +0000 |
| Message-ID | <slrnjf6srb.1tui.usenet-nospam@guild.seebs.net> |
| In reply to | #14870 |
On 2011-12-22, BartC <bc@freeuk.com> wrote: > "Seebs" <usenet-nospam@seebs.net> wrote in message > news:slrnjf6ocv.1rti.usenet-nospam@guild.seebs.net... >> On 2011-12-22, 88888 Dihedral <dihedral88888@googlemail.com> wrote: >>> Do you consider to convert 5 to 10 lines of C to assembly? >> Of course not. >> 1. It's a great way to introduce errors and bugs. > Well, you could say that same about using C! Compared to something higher > level, safer, but slower. True. And I use C, for the most part, only when I have a specific and compelling reason to work at that level. >> 2. It eliminates portability. > So what? If this is a product to be sold/used in thousands and millions, > you'll probably find that a small number of platforms will dominate. Then > it's worth producing a custom version for the top one or two. The rest can > use the slow version. It might be worth producing a custom version... IF you knew that this particular small hunk of code was actually that expensive to run, and was being run enough to matter, and performance was remotely an issue. But that's a very, very, rare circumstance. > If you're distributing the code as binaries, then you will need multiple > versions anyway. And if you're distributing as source code, you will have > just as many headaches with getting the right combinations of compiler, > compiler switches, makefiles and libraries that will work 'out-of-the-box' > on anything. Not just as many. Trust me! I work on a build system that has to manage about 60 targets. The handful of programs that have assembly hacks which are optional in some way consume a very noticably disproportionate amount of time because of all the extra hassles they introduce *on top of* all the stuff with compilers and compiler switches. >> 3. It takes time. >> 4. It is very unlikely to produce a measurable benefit. > You're assuming this is for a one-off program that will only be run once. > Then you could well spend more time programming than will be saved in > runtime. But usually that is not the case. No, I'm including cases where a program is run millions of times. There is a reason that the vast majority of programs don't contain inline assembly, and it's not that software developers are stupid. >> When you're about to pop out to the store, do you take your car's fuel >> system apart and rebuild the carburetor? > But if you're working in automobile design and production, this is just the > sort of thing you might do. Then you end with a version with a very slightly > better fuel consumption, but which is significant over a million units and > thousands of journeys each. The key to the analogy is that they haven't used carburetors in something over a decade in any major line of vehicles I'm aware of. A significant improvement in the perforumance of a carburetor isn't even remotely competitive with a cheap fuel injection system. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | superpollo <superpollo@tznvy.pbz> |
|---|---|
| Date | 2011-12-22 20:00 +0100 |
| Message-ID | <4ef37e66$0$1377$4fafbaef@reader2.news.tin.it> |
| In reply to | #14871 |
Seebs ha scritto: > On 2011-12-22, BartC <bc@freeuk.com> wrote: >> "Seebs" <usenet-nospam@seebs.net> wrote in message >> news:slrnjf6ocv.1rti.usenet-nospam@guild.seebs.net... >>> On 2011-12-22, 88888 Dihedral <dihedral88888@googlemail.com> wrote: >>>> Do you consider to convert 5 to 10 lines of C to assembly? > >>> Of course not. > >>> 1. It's a great way to introduce errors and bugs. > >> Well, you could say that same about using C! Compared to something higher >> level, safer, but slower. > > True. And I use C, for the most part, only when I have a specific and > compelling reason to work at that level. maybe that's offtopic, but i am curious: what languages and tools do you use most for your work? bye -- - La verdad amigo, es que en tu sangre, tienes mierda! - Es posible, pero la mierda viva es mejor que la mierda muerta... - Amigo... la mierda, siempre mierda es!!
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-12-22 19:08 +0000 |
| Message-ID | <slrnjf71tg.20t7.usenet-nospam@guild.seebs.net> |
| In reply to | #14874 |
On 2011-12-22, superpollo <superpollo@tznvy.pbz> wrote: > Seebs ha scritto: >> True. And I use C, for the most part, only when I have a specific and >> compelling reason to work at that level. > maybe that's offtopic, but i am curious: what languages and tools do you > use most for your work? Boy, that's pretty open-ended. Right now, my favorite language in which to express something is Ruby; if I don't really know how to do something yet, that seems to be a very friendly language in which to try to figure it out. Also very nice for refactoring. I love me some Rails. I use PHP for things which had to be in PHP for compatibility at some point in the past, but I hate it. It is a stupendously bad language. I use various modern derivatives of Bourne shell, and Makefile type stuff, and perl, all as-needed. Not super fond of them as languages, although the shell really is extremely powerful as glue. I use Lua a fair bit, largely because I play RIFT (really nice MMO), and that's what their addon API is done in. (If you've ever wanted to mess around with addon development in video games, the guy doing the RIFT API is a genius, and while the API isn't complete yet, the parts it has really are delightful to use.) The main thing I'm using C for these days is pseudo, which is a program which intercepts calls into libc (and thus in effect most system calls) and fakes up a virtual root environment; we use this for a build system to allow the creation of filesystem images with ownership and permissions and devices, without needing root access. (It's similar to fakeroot, but different in a few philosophical ways.) As an interesting example, I do plan to write something in C "soon", which is a wrapper. Right now the wrapper is implemented as a shell script, but we have performance issues with that which mandate a reimplementation. This is a case where we know this wrapper has to run millions of times, and the performance overhead really DOES matter. (We'd do it in a more efficient scripting language, but for Various Sound Technical Reasons, we end up being unable to do this.) -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | superpollo <superpollo@tznvy.pbz> |
|---|---|
| Date | 2011-12-22 22:43 +0100 |
| Message-ID | <4ef3a47d$0$1387$4fafbaef@reader2.news.tin.it> |
| In reply to | #14879 |
Seebs ha scritto: > On 2011-12-22, superpollo <superpollo@tznvy.pbz> wrote: >> Seebs ha scritto: >>> True. And I use C, for the most part, only when I have a specific and >>> compelling reason to work at that level. > >> maybe that's offtopic, but i am curious: what languages and tools do you >> use most for your work? > > Boy, that's pretty open-ended. > > Right now, my favorite language in which to express something is Ruby; if I > don't really know how to do something yet, that seems to be a very friendly > language in which to try to figure it out. Also very nice for refactoring. > I love me some Rails. > > I use PHP for things which had to be in PHP for compatibility at some point > in the past, but I hate it. It is a stupendously bad language. > > I use various modern derivatives of Bourne shell, and Makefile type stuff, > and perl, all as-needed. Not super fond of them as languages, although the > shell really is extremely powerful as glue. i concur. > I use Lua a fair bit, largely because I play RIFT (really nice MMO), and > that's what their addon API is done in. (If you've ever wanted to mess > around with addon development in video games, the guy doing the RIFT API > is a genius, and while the API isn't complete yet, the parts it has really > are delightful to use.) gonna check that out. > The main thing I'm using C for these days is pseudo, which is a program > which intercepts calls into libc (and thus in effect most system calls) > and fakes up a virtual root environment; we use this for a build system > to allow the creation of filesystem images with ownership and permissions > and devices, without needing root access. (It's similar to fakeroot, but > different in a few philosophical ways.) > > As an interesting example, I do plan to write something in C "soon", which > is a wrapper. Right now the wrapper is implemented as a shell script, but > we have performance issues with that which mandate a reimplementation. > This is a case where we know this wrapper has to run millions of times, > and the performance overhead really DOES matter. (We'd do it in a more > efficient scripting language, but for Various Sound Technical Reasons, we is "Various Sound Technical Reasons" a trademark? ;-) > end up being unable to do this.) > > -s thanks for sharing this info. bye -- - La verdad amigo, es que en tu sangre, tienes mierda! - Es posible, pero la mierda viva es mejor que la mierda muerta... - Amigo... la mierda, siempre mierda es!!
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-12-22 21:57 +0000 |
| Message-ID | <slrnjf79tj.24nn.usenet-nospam@guild.seebs.net> |
| In reply to | #14886 |
On 2011-12-22, superpollo <superpollo@tznvy.pbz> wrote: > is "Various Sound Technical Reasons" a trademark? ;-) Probably. It's sort of like historical reasons, only slightly more justifiable. There's an idiom where capitalizing terms makes them look like proper nouns, invoking the suggestion that they are references to specific well-known things which could be described by those words. "Various Sound Technical Reasons" means roughly the same thing as "there were a series of discussions and proposed alternatives all of which were considered but shot down because of perfectly good technical arguments which are too long to go into here, and we've all had experiences like that where at the end of three months of design discussions all you really remember is that there were sound technical reasons none of which are easy to articulate." -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | BruceS <bruces42@hotmail.com> |
|---|---|
| Date | 2011-12-23 16:26 -0800 |
| Message-ID | <3a458e6c-f5e1-4411-9c1b-b3009e6a9b18@n39g2000yqh.googlegroups.com> |
| In reply to | #14871 |
On Dec 22, 11:14 am, Seebs <usenet-nos...@seebs.net> wrote: <snip> > The key to the analogy is that they haven't used carburetors in something over > a decade in any major line of vehicles I'm aware of. Harley Davidson FTW.
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-12-22 19:21 +0000 |
| Message-ID | <jcvvvd$j97$1@speranza.aioe.org> |
| In reply to | #14870 |
BartC wrote: >> 2. It eliminates portability. > > So what? If this is a product to be sold/used in thousands and millions, > you'll probably find that a small number of platforms will dominate. Then > it's worth producing a custom version for the top one or two. The rest can > use the slow version. I don't believe that the idea of replacing C with assembly, in this context, meant that the assembly instructions represented specialized routines for a specific platform. In this context, replacing C with assembly meant replacing C with assembly, in the sense that the routine consisted of a single specialized piece of code which could only run on a very specific platform and that there wasn't any alternative to it. >> 4. It is very unlikely to produce a measurable benefit. > > You're assuming this is for a one-off program that will only be run once. > Then you could well spend more time programming than will be saved in > runtime. But usually that is not the case. Not necessarily. Nowadays compilers do churn out optimized code, and chances are they do a far better job at it than any random programmer. This means that, just by tweaking a single compiler flag, we may get all the optimizations which any random programmer might be able to use, without wasting days rewriting stuff and while avoiding to increase the complexity of our project. And there's of course the risk of potentially introducing new non-trivial bugs which aren't easily catched, even with a debugger. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2011-12-22 11:33 -0800 |
| Message-ID | <22609158.418.1324582435845.JavaMail.geo-discussion-forums@prez15> |
| In reply to | #14875 |
On Friday, December 23, 2011 3:21:24 AM UTC+8, Rui Maciel wrote: > BartC wrote: > > >> 2. It eliminates portability. > > > > So what? If this is a product to be sold/used in thousands and millions, > > you'll probably find that a small number of platforms will dominate. Then > > it's worth producing a custom version for the top one or two. The rest can > > use the slow version. > > I don't believe that the idea of replacing C with assembly, in this context, > meant that the assembly instructions represented specialized routines for a > specific platform. In this context, replacing C with assembly meant > replacing C with assembly, in the sense that the routine consisted of a > single specialized piece of code which could only run on a very specific > platform and that there wasn't any alternative to it. > > Of course this in not for low novices in C. > >> 4. It is very unlikely to produce a measurable benefit. > > > > You're assuming this is for a one-off program that will only be run once. > > Then you could well spend more time programming than will be saved in > > runtime. But usually that is not the case. > > Not necessarily. Nowadays compilers do churn out optimized code, and > chances are they do a far better job at it than any random programmer. This > means that, just by tweaking a single compiler flag, we may get all the > optimizations which any random programmer might be able to use, without > wasting days rewriting stuff and while avoiding to increase the complexity > of our project. And there's of course the risk of potentially introducing > new non-trivial bugs which aren't easily catched, even with a debugger. > > > Rui Maciel I suggest you should use VB for happy programming or some other high level languages, please google for books about C and mixed assembly programming.
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-12-23 09:10 +0100 |
| Message-ID | <4ef43690$0$1377$4fafbaef@reader2.news.tin.it> |
| In reply to | #14875 |
"Rui Maciel" <rui.maciel@gmail.com> ha scritto nel messaggio news:jcvvvd$j97$1@speranza.aioe.org... > BartC wrote: > Not necessarily. Nowadays compilers do churn out optimized code, and > chances are they do a far better job at it than any random programmer. i claim that the above is false if the code generated is not easy scalable, not easy comprensible by humans i'm sorry, but compilers not has to write algoritms for you you have to write algoritms and the compiler has to traslate them litterally > This > means that, just by tweaking a single compiler flag, we may get all the > optimizations which any random programmer might be able to use, without > wasting days rewriting stuff and while avoiding to increase the complexity > of our project. And there's of course the risk of potentially introducing > new non-trivial bugs which aren't easily catched, even with a debugger. > > > Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-12-23 14:43 +0000 |
| Message-ID | <jd2438$1ld$1@speranza.aioe.org> |
| In reply to | #14900 |
io_x wrote: >> Not necessarily. Nowadays compilers do churn out optimized code, and >> chances are they do a far better job at it than any random programmer. > > i claim that the above is false if the code generated is not easy > scalable, not easy comprensible by humans > i'm sorry, but compilers not has to write algoritms for you > you have to write algoritms and the compiler has to traslate them > litterally My assertion wasn't based on the idea that compilers have to write algorithms. My assertion is that, given any algorithm expressed by any random programmer, the set of optimization techniques which have been implemented in today's popular compilers end up generating code which is more efficient than that which would otherwise be written by hand by any random programmer. Naturally, there is always someone somewhere who is quite capable of performing enough code voodoo to churn out more efficient code than that which is produced by a compiler. Even in that case, there is the problem of how fast he is able to write it, how fast the code is executed and the relation between how much time was spent writing it and the added value which has been obtained. As a somewhat related oddity, here is a talk by Guy Steele himself[1]. In it, he discusses some techniques he employed to write a couple of programs, along with some optimization tricks he employed. Among those, he refers in some parts how he reduced the program size by using the value of some opcodes as constants. I doubt that today's compiler writers implement these sort of tricks. This means that mr Steele's code is better than the equivalent code which might be generated by a compiler. But the thing is, not everyone is as proficient at it as mr Steele, or even close to it, which brings us back to the assertion I've made. Rui Maciel [1] http://www.infoq.com/presentations/Thinking-Parallel-Programming
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-12-23 17:14 +0000 |
| Message-ID | <0.3050587867cc06ccb088.20111223171456GMT.87sjkbjjlb.fsf@bsb.me.uk> |
| In reply to | #14917 |
Rui Maciel <rui.maciel@gmail.com> writes: > This means that mr Steele's code is better than the > equivalent code which might be generated by a compiler. But the thing is, > not everyone is as proficient at it as mr Steele, or even close to it, which > brings us back to the assertion I've made. s/Mr/Dr/ Not that people bother so much with titles these days, but if you are going to be formal, using the wrong one defeats the purpose! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-12-23 12:10 -0800 |
| Message-ID | <ln39cb2gmq.fsf@nuthaus.mib.org> |
| In reply to | #14917 |
Rui Maciel <rui.maciel@gmail.com> writes:
[...]
> As a somewhat related oddity, here is a talk by Guy Steele himself[1]. In
> it, he discusses some techniques he employed to write a couple of programs,
> along with some optimization tricks he employed. Among those, he refers in
> some parts how he reduced the program size by using the value of some
> opcodes as constants. I doubt that today's compiler writers implement these
> sort of tricks. This means that mr Steele's code is better than the
> equivalent code which might be generated by a compiler. But the thing is,
> not everyone is as proficient at it as mr Steele, or even close to it, which
> brings us back to the assertion I've made.
>
> [1] http://www.infoq.com/presentations/Thinking-Parallel-Programming
It would be better in the sense that it's *faster*. It would
probably not be very maintainable (by anyone other than Dr. Steele).
Imagine modifying the code when the value of one of those constants
needs to change.
A great benefit of automatically generated code, such as the assembly
or machine code generated by a compiler, is that it doesn't *have*
to be maintained. All the work that went into optimizing it can
be thrown away and re-done, perhaps very differently, in a matter
of moments.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2012-01-03 14:24 -0500 |
| Message-ID | <4F035609.2E6947C8@bytecraft.com> |
| In reply to | #14870 |
BartC wrote: > > When you're about to pop out to the store, do you take your car's fuel > > system apart and rebuild the carburetor? > > But if you're working in automobile design and production, this is just the > sort of thing you might do. Then you end with a version with a very slightly > better fuel consumption, but which is significant over a million units and > thousands of journeys each. I have worked in automotive for close to a couple decades and it is the type of thing that this industry would not do for a couple reasons. First there is very few things that can be done in asm that cannot be done in C. Very few as in some C compilers actually check that everything that can be done in asm can be done in C. Engine control code in current automotive applications has not been written is not in a timing sensitive code eliminating that as an incentive. As several others have said support of embedded asm is just too unreliable and unneeded in the applications now. I am willing to bet that in the compilers we have developed I can write anything in C that can be written in asm in equal or less code space with equal or less execution time. Regards, Walter.. -- Walter Banks Byte Craft Limited http://www.bytecraft.com
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2012-01-03 19:58 +0000 |
| Message-ID | <20120103113739.535@kylheku.com> |
| In reply to | #15379 |
On 2012-01-03, Walter Banks <walter@bytecraft.com> wrote: > > > BartC wrote: > >> > When you're about to pop out to the store, do you take your car's fuel >> > system apart and rebuild the carburetor? >> >> But if you're working in automobile design and production, this is just the >> sort of thing you might do. Then you end with a version with a very slightly >> better fuel consumption, but which is significant over a million units and >> thousands of journeys each. > > I have worked in automotive for close to a couple decades and it is the type > of thing that this industry would not do for a couple reasons. > > First there is very few things that can be done in asm that cannot be done in C. However, those things are of high importance. Just maybe not to some C programmers. Assembly gives you the access to the machine at a level that allows you to implement things like accurate stack unwinding, exception handling and completely precise garbage collection. Not all of these can be done by merely calling assembly routines or inline code from C, because they depend coding conventions, and so control over the compiler is necessary). If your view of computing embraces such capabilities, then you will find assembly language to be more capable than C. For instance, take garbage collection. Suppose that in some function there is a statement "x = NULL", where x is local and there are no more uses of x in the remaining block. An optimizing C compiler could simply not bother with this assignment since x has no next use. But what if there is garbage collection? The variable x could be the last reference to a large amount of memory, whose reclamation will be prevented if the assignment is optimized away. The C compiler does not know that x has a kind of next use: it can be visited "behind the scenes" by the garbage collector! C compilers are GC-unfriendly in numerous ways, one of which is this generation of semantic garbage: keeping values in memory or registers beyond the point at which they have become garbage in the source semantics. In assembly we don't have this problem; since we know what we put into every memory location and register. We would like to be able to extend the C compiler with new rules such as "whenever a pointer variable has no next use, generate code to overwrite it with null", but the language doesn't give us a way to direct the translation in such ways. > Very few as in some C compilers actually check that everything that can be > done in asm can be done in C. Really? An example or two would go a long way here.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2012-01-03 16:15 -0500 |
| Message-ID | <4F036FE2.6B947764@bytecraft.com> |
| In reply to | #15381 |
Kaz Kylheku wrote: > > Very few as in some C compilers actually check that everything that can be > > done in asm can be done in C. > > Really? An example or two would go a long way here. http://bytecraft.com/C_versus_Assembly w..
[toc] | [prev] | [next] | [standalone]
| From | blp@cs.stanford.edu (Ben Pfaff) |
|---|---|
| Date | 2012-01-03 13:26 -0800 |
| Message-ID | <87pqf0fpfk.fsf@blp.benpfaff.org> |
| In reply to | #15386 |
Walter Banks <walter@bytecraft.com> writes: > Kaz Kylheku wrote: > >> > Very few as in some C compilers actually check that everything that can be >> > done in asm can be done in C. >> >> Really? An example or two would go a long way here. > > http://bytecraft.com/C_versus_Assembly I found it odd that the compiler generated any code at all for "AC - page0;" or "(void)AC - page0;". -- "You call this a *C* question? What the hell are you smoking?" --Kaz
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2012-01-03 22:04 +0000 |
| Message-ID | <20120103132417.186@kylheku.com> |
| In reply to | #15386 |
On 2012-01-03, Walter Banks <walter@bytecraft.com> wrote: > > > Kaz Kylheku wrote: > >> > Very few as in some C compilers actually check that everything that can be >> > done in asm can be done in C. >> >> Really? An example or two would go a long way here. > > http://bytecraft.com/C_versus_Assembly In machine language, we can, for instance, disable interrupts, flush an instruction cache, or save the registers to a stack. To show that everything that can be done in assembly can be done in C, you have to show how these things are done. The paper does not show such things. The paper argues that in the domain of translating calculation formulas, a compiler can select instructions as well as human programmer. (And that with some extensions to C, like "char small @0x15;" or "registerx xreg;" we can even coerce the selection of particular operands to match specific instances of assembly language.) This has not been controversial for decades; the paper belongs more in 1966, or maybe 1976, than in 2006. Still, even in this restricted domain, there are things compilers will typically not do. For instance, select some very complex instructions, where it is difficult to identify the pattern of C code which fits them exactly (but the assembly language programmer can contrive the surrounding code to exploit the CISC instruction). Or, custom microcoding: make your own machine language instruction and then use it. Leveling the field between humans and compilers in this area required the development of RISC architectures (in which you basically write microcode, so there are no complex instructions that the programmer could use, and no lower level microcode kernel to escape into to beat the compiler.) These days, if you're finding that you can't beat the C compiler by coding in assembly language, chances are it's in large part because the assembly language is designed to work well as a target language for C compilers! That has not historically been the case. Because of the things that assembly language can do that C really cannot (by design) assembly language is actually a better tool for bootstrapping a high quality implementation of some high level languages. For instance, the best quality Lisp implementations use very little or no C internally, and, in particular, avoid compiling to C, or using C for run-time code that is directly called from the language. You don't want the image of a function, the basic unit of the program, to be controlled by a C compiler because then you have all these uncertainties such as calling conventions, register use, etc. that are only specific to a compiler, but specific to how a given compiler is invoked.
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web