Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #14925 > unrolled thread
| Started by | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| First post | 2011-12-23 18:43 +0000 |
| Last post | 2012-01-10 18:00 +0100 |
| Articles | 9 on this page of 109 — 24 participants |
Back to article view | Back to comp.lang.c
Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-23 18:43 +0000
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-23 19:40 +0000
Re: Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-23 21:26 +0000
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-23 22:02 +0000
Re: Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-24 02:52 +0000
Re: Performance of hand-optimised assembly 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-23 20:32 -0800
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-24 13:09 +0000
Re: Performance of hand-optimised assembly James Harris <james.harris.1@googlemail.com> - 2011-12-24 05:49 -0800
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-24 15:30 +0000
Re: Performance of hand-optimised assembly James Harris <james.harris.1@googlemail.com> - 2011-12-24 08:15 -0800
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-24 17:10 +0000
Re: Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-24 23:25 +0000
Re: Performance of hand-optimised assembly jgk@panix.com (Joe keane) - 2012-01-04 03:24 +0000
Re: Performance of hand-optimised assembly jacob navia <jacob@spamsink.net> - 2012-01-04 09:59 +0100
Re: Performance of hand-optimised assembly jgk@panix.com (Joe keane) - 2012-01-04 20:57 +0000
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2012-01-04 23:04 +0000
Re: Performance of hand-optimised assembly Noob <root@127.0.0.1> - 2012-01-05 13:32 +0100
Re: Performance of hand-optimised assembly Philip Lantz <prl@canterey.us> - 2011-12-24 15:29 -0800
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-24 12:42 +0000
Re: Performance of hand-optimised assembly Jens Gustedt <jens.gustedt@loria.fr> - 2011-12-24 16:58 +0100
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-24 13:55 +0000
Re: Performance of hand-optimised assembly Seebs <usenet-nospam@seebs.net> - 2011-12-24 19:24 +0000
Re: Performance of hand-optimised assembly Geoff <geoff@invalid.invalid> - 2011-12-24 13:44 -0800
Re: Performance of hand-optimised assembly Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-12-29 02:53 +0200
Re: Performance of hand-optimised assembly Rui Maciel <rui.maciel@gmail.com> - 2011-12-29 02:11 +0000
Re: Performance of hand-optimised assembly jgk@panix.com (Joe keane) - 2011-12-24 01:36 +0000
Re: Performance of hand-optimised assembly "io_x" <a@b.c.invalid> - 2011-12-24 06:44 +0100
Re: Performance of hand-optimised assembly "io_x" <a@b.c.invalid> - 2011-12-24 09:52 +0100
Re: Performance of hand-optimised assembly "io_x" <a@b.c.invalid> - 2011-12-26 08:05 +0100
Re: Performance of hand-optimised assembly 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-26 11:52 -0800
Re: Performance of hand-optimised assembly "io_x" <a@b.c.invalid> - 2011-12-27 07:28 +0100
Re: Performance of hand-optimised assembly Willem <willem@toad.stack.nl> - 2011-12-24 12:48 +0000
Re: Performance of hand-optimised assembly 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-24 04:56 -0800
Re: Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-24 23:39 +0000
Re: Performance of hand-optimised assembly James Harris <james.harris.1@googlemail.com> - 2011-12-24 06:01 -0800
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-24 14:55 +0000
Re: Performance of hand-optimised assembly James Harris <james.harris.1@googlemail.com> - 2011-12-28 03:46 -0800
Re: Performance of hand-optimised assembly 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-28 04:52 -0800
Re: Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-25 00:07 +0000
Re: Performance of hand-optimised assembly James Harris <james.harris.1@googlemail.com> - 2011-12-28 03:21 -0800
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-28 13:19 +0000
Re: Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-28 16:01 +0000
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-28 17:45 +0000
Re: Performance of hand-optimised assembly 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-28 18:56 -0800
Re: Performance of hand-optimised assembly Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-12-29 03:32 +0200
Re: Performance of hand-optimised assembly Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 17:03 -0800
Re: Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-26 22:08 +0000
Re: Performance of hand-optimised assembly Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 22:20 -0800
Re: Performance of hand-optimised assembly James Kuyper <jameskuyper@verizon.net> - 2011-12-28 08:24 -0500
Re: Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-28 14:27 +0000
Re: Performance of hand-optimised assembly Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 16:50 -0800
Re: Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-26 21:59 +0000
Re: Performance of hand-optimised assembly James Harris <james.harris.1@googlemail.com> - 2011-12-28 11:12 -0800
Re: Performance of hand-optimised assembly Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-12-29 03:12 +0200
Re: Performance of hand-optimised assembly jacob navia <jacob@spamsink.net> - 2011-12-29 10:02 +0100
Re: Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-29 12:06 +0000
Re: Performance of hand-optimised assembly Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 17:07 -0800
Re: Performance of hand-optimised assembly Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-13 01:18 +0200
Re: Performance of hand-optimised assembly Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 10:54 -0800
Re: Performance of hand-optimised assembly jacob navia <jacob@spamsink.net> - 2011-12-29 10:02 +0100
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-29 12:06 +0000
Re: Performance of hand-optimised assembly Keith Thompson <kst-u@mib.org> - 2011-12-29 11:44 -0800
Re: Performance of hand-optimised assembly Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 17:23 -0800
Re: Performance of hand-optimised assembly James Harris <james.harris.1@googlemail.com> - 2011-12-29 08:37 -0800
Re: Performance of hand-optimised assembly Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-01-05 22:19 +0200
Re: Performance of hand-optimised assembly James Dow Allen <gmail@jamesdowallen.nospam> - 2011-12-24 16:21 +0000
Re: Performance of hand-optimised assembly Weland <weland@otaku.freeshell.org> - 2011-12-25 10:54 +0000
Re: Performance of hand-optimised assembly "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-12-24 14:52 -0800
Re: Performance of hand-optimised assembly jacob navia <jacob@spamsink.net> - 2011-12-25 20:12 +0100
Re: Performance of hand-optimised assembly 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-25 11:36 -0800
Re: Performance of hand-optimised assembly jacob navia <jacob@spamsink.net> - 2011-12-25 21:35 +0100
Re: Performance of hand-optimised assembly Stephen Sprunk <stephen@sprunk.org> - 2011-12-26 14:24 -0600
Re: Performance of hand-optimised assembly jacob navia <jacob@spamsink.net> - 2011-12-26 21:36 +0100
Re: Performance of hand-optimised assembly Stephen Sprunk <stephen@sprunk.org> - 2012-01-04 11:59 -0600
Re: Performance of hand-optimised assembly jacob navia <jacob@spamsink.net> - 2012-01-04 20:22 +0100
Re: Performance of hand-optimised assembly Dann Corbit <dcorbit@connx.com> - 2012-01-04 12:59 -0800
Re: Performance of hand-optimised assembly James Harris <james.harris.1@googlemail.com> - 2012-01-04 15:32 -0800
Re: Performance of hand-optimised assembly Stephen Sprunk <stephen@sprunk.org> - 2012-01-05 23:47 -0600
Re: Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-04 22:47 +0000
Re: Performance of hand-optimised assembly jacob navia <jacob@spamsink.net> - 2012-01-05 00:47 +0100
Re: Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-05 00:22 +0000
Re: Performance of hand-optimised assembly 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-04 23:44 -0800
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2012-01-05 12:16 +0000
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2012-01-05 12:49 +0000
Re: Performance of hand-optimised assembly jgk@panix.com (Joe keane) - 2012-01-05 21:26 +0000
Re: Performance of hand-optimised assembly "io_x" <a@b.c.invalid> - 2012-01-07 10:32 +0100
Re: Performance of hand-optimised assembly jacob navia <jacob@spamsink.net> - 2012-01-05 00:58 +0100
Re: Performance of hand-optimised assembly 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-05 13:39 -0800
Re: Performance of hand-optimised assembly 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-07 02:15 -0800
Re: Performance of hand-optimised assembly 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-10 01:07 -0800
Re: Performance of hand-optimised assembly jgk@panix.com (Joe keane) - 2012-01-07 00:49 +0000
Re: Performance of hand-optimised assembly jacob navia <jacob@spamsink.net> - 2012-01-07 08:54 +0100
Re: Performance of hand-optimised assembly jacob navia <jacob@spamsink.net> - 2012-01-07 10:11 +0100
Re: Performance of hand-optimised assembly "io_x" <a@b.c.invalid> - 2012-01-07 10:51 +0100
Re: Performance of hand-optimised assembly jgk@panix.com (Joe keane) - 2012-01-07 20:09 +0000
Re: Performance of hand-optimised assembly Stephen Sprunk <stephen@sprunk.org> - 2012-01-06 23:39 -0600
Re: Performance of hand-optimised assembly jacob navia <jacob@spamsink.net> - 2012-01-07 10:33 +0100
Re: Performance of hand-optimised assembly Stephen Sprunk <stephen@sprunk.org> - 2012-01-07 07:36 -0600
Re: Performance of hand-optimised assembly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-07 21:03 +0000
Re: Performance of hand-optimised assembly Stephen Sprunk <stephen@sprunk.org> - 2012-01-07 16:42 -0600
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-25 20:23 +0000
Re: Performance of hand-optimised assembly jacob navia <jacob@spamsink.net> - 2011-12-25 21:50 +0100
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-25 22:10 +0000
Re: Performance of hand-optimised assembly 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-25 13:11 -0800
Re: Performance of hand-optimised assembly "BartC" <bc@freeuk.com> - 2011-12-25 22:07 +0000
Re: Performance of hand-optimised assembly 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-25 16:39 -0800
Re: Performance of hand-optimised assembly "io_x" <a@b.c.invalid> - 2011-12-26 05:55 +0100
Re: Performance of hand-optimised assembly "io_x" <a@b.c.invalid> - 2012-02-17 17:58 +0100
Re: Performance of hand-optimised assembly "Wolfgang.Draxinger" <Wolfgang.Draxinger@physik.uni-muenchen.de> - 2012-01-10 18:00 +0100
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2011-12-25 20:23 +0000 |
| Message-ID | <jd80o1$18g$1@dont-email.me> |
| In reply to | #14987 |
"jacob navia" <jacob@spamsink.net> wrote in message
news:jd7sjj$gum$1@speranza.aioe.org...
> 1) Nobody knows assembly here, besides io_x that is the only one
> that really answered the question and presented an assembly
> language program.
He did, but it's not clear how closely it corresponds to the C algorithm
presented. And anyway it seemed the results were of more interest than the
details, which are obviously going to be very specific to processor,
assembler, language and compiler.
(But here anyway is the asm code I used, in Nasm format, for x86-32, and
used as inline code for the body of a function taking parameters a, length
and key:
%define rlow ebx
%define rhigh ecx
%define rmiddle eax
%define rkey edi
%define rdata esi
mov rdata,[a]
mov rhigh,[length]
mov rkey,[key]
mov rlow,0
lab1:
cmp rhigh,rlow
jle labx
mov rmiddle,rhigh
sub rmiddle,rlow
shr rmiddle,1
add rmiddle,rlow
cmp [rmiddle*4+rdata],rkey
jz labret
jge lab3
lea rlow,[rmiddle+1]
jmp lab1
lab3:
mov rhigh,rmiddle
jmp lab1
labx: mov eax,-1
labret:
pop ebp
retn 12
)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-12-25 21:50 +0100 |
| Message-ID | <jd82a7$si6$1@speranza.aioe.org> |
| In reply to | #14991 |
Interesting but I see some parts missing: Where is the entry point and interface of the routine? You do a pop ebp at the end but I do not see the corresponging push. Anyway one of the optimizations that a programmer can do and a compiler can't are the program specific hacks. For instance if you call a routine once or twice and the routine's code is available you can extend the calling convention to *anything* what you basically assume when you suppose rdata in esi. This can be extended to squeeze some performance by minimizing moves That is difficult for a specific case. The programmer must be right for *THIS* program and this data; a compiler must be correct for ALL pssible programs what is another pair of shoes... QUITE another. But even at this scale assembly language manipulations are very error prone, as every asm programmer knows very well. The more you hack into calling conventions, the less manageable and modifiable is your code. GREAT! You do not move the data at all. But... what do you do when you need one more argument or to use that routine from the outside? Every usage needs a rewriting in assembly of the calling routine. Or a "sas", a routine that translates into the ad-hoc routine with just push/pop. But that is going to be MUCH slower... etc. You must know the limits.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2011-12-25 22:10 +0000 |
| Message-ID | <jd873g$34c$2@dont-email.me> |
| In reply to | #14993 |
"jacob navia" <jacob@spamsink.net> wrote in message
news:jd82a7$si6$1@speranza.aioe.org...
> Interesting but I see some parts missing:
>
> Where is the entry point and interface of the routine?
>
> You do a pop ebp at the end but I do not see the
> corresponging push.
The rest of the code is generated by the compiler. Immediately prior to the
start of the asm code, it will execute:
mov esi,[ebp-40] ;<data>
push dword [esi]
push dword 0
push dword [ebp-40] ;<data>
call binsearch
...
binsearch:
push ebp
mov ebp,esp ;
And on returning from the function:
add [ebp-20],eax ;<sum>
Nothing unexpected. (Note in the asm I posted, the host compiler will
convert [a], etc to [ebp+offset] before passing to the external assembler)
> hacks. For instance if you call a routine once or
> twice and the routine's code is available you can
> extend the calling convention to *anything* what
> you basically assume when you suppose rdata in esi.
rdata (which is just register esi) is loaded from the parameter 'a' inside
the function; there are no dependencies outside the function. (And this host
language - of the inline assembly - does not require register-saving.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2011-12-25 13:11 -0800 |
| Message-ID | <6774548.117.1324847477383.JavaMail.geo-discussion-forums@preg20> |
| In reply to | #14991 |
Bart於 2011年12月26日星期一UTC+8上午4時23分21秒寫道： > "jacob navia" <ja...@spamsink.net> wrote in message > news:jd7sjj$gum$1@speranza.aioe.org... > > > 1) Nobody knows assembly here, besides io_x that is the only one > > that really answered the question and presented an assembly > > language program. > > He did, but it's not clear how closely it corresponds to the C algorithm > presented. And anyway it seemed the results were of more interest than the > details, which are obviously going to be very specific to processor, > assembler, language and compiler. > > (But here anyway is the asm code I used, in Nasm format, for x86-32, and > used as inline code for the body of a function taking parameters a, length > and key: > > %define rlow ebx > %define rhigh ecx > %define rmiddle eax > %define rkey edi > %define rdata esi > > mov rdata,[a] > mov rhigh,[length] > mov rkey,[key] > mov rlow,0 > > lab1: ;while gap > cmp rhigh,rlow > jle labx ; zero gap version ; no need for gap>1 > > mov rmiddle,rhigh > sub rmiddle,rlow > shr rmiddle,1 divide by 2 > add rmiddle,rlow get the middle index > > cmp [rmiddle*4+rdata],rkey SHL ? > jz labret > jge lab3 > > lea rlow,[rmiddle+1] > jmp lab1 > > lab3: > mov rhigh,rmiddle > jmp lab1 > > labx: mov eax,-1 > labret: > pop ebp > retn 12 > > ) > -- > Bartc
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2011-12-25 22:07 +0000 |
| Message-ID | <jd873f$34c$1@dont-email.me> |
| In reply to | #14994 |
"88888 Dihedral" <dihedral88888@googlemail.com> wrote in message
news:6774548.117.1324847477383.JavaMail.geo-discussion-forums@preg20...
> Bart於 2011年12月26日星期一UTC+8上午4時23分21秒寫道：
>> %define rlow ebx
>> %define rhigh ecx
>> %define rmiddle eax
>> %define rkey edi
>> %define rdata esi
> ;while gap
> ; zero gap version
> ; no need for gap>1
Sorry I didn't see the need for comments (in fact I took them out).
The code corresponds accurately to the original C (see OP) and with comments
is:
mov rdata,[a]
mov rhigh,[length] ;high=length
mov rkey,[key]
mov rlow,0 ;low=0
lab1:
cmp rhigh,rlow ;while high>low
jle labx
mov rmiddle,rhigh ;middle=(high-low)/2+low
sub rmiddle,rlow
shr rmiddle,1
add rmiddle,rlow
cmp [rmiddle*4+rdata],rkey ;if a[middle]==key
jz labret ; return middle (rmiddle already is
eax)
jge lab3 ;else if a[middle]>key
lea rlow,[rmiddle+1] ;low=middle+1
jmp lab1
lab3:
mov rhigh,rmiddle ;high=middle (in case it's not obvious)
jmp lab1
labx:
mov eax,-1 ;return -1
labret:
pop ebp
retn 12
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2011-12-25 16:39 -0800 |
| Message-ID | <28996249.27.1324859945804.JavaMail.geo-discussion-forums@prlu4> |
| In reply to | #14995 |
You are good in assembly and C. Well done!
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-12-26 05:55 +0100 |
| Message-ID | <4ef7fd4d$0$1389$4fafbaef@reader2.news.tin.it> |
| In reply to | #14925 |
"Ben Bacarisse" <ben.usenet@bsb.me.uk> ha scritto nel messaggio news:0.d0ecd8f477637819bed2.20111223184332GMT.87pqffjfhn.fsf@bsb.me.uk... > I'm starting a new thread, but it is prompted by this remark from 88888 > Dihedral <dihedral88888@googlemail.com> about a short binary search > function I posted: > > | Do you consider to convert 5 to 10 lines of C to assembly? > | I did that 20 years ago on X86 cpu. > | It was a piece of cake to gain the 20-40% speed required if paid > | well. > > I've felt (it's only a feeling) that hand coding for speed (rather than > to access features not available in C like extra wide multiplies and so > on) was a thing of the past. But maybe I'm wrong. Is it still possible > to get a significant speed-up over C by hand coding? How much depends > on the processor? How good are the modern optimising compilers that > would have to be beaten? > > Since I don't know enough about modern CPUs to stand much chance of > improving on gcc, I thought I'd post this for others to try. Maybe > you'll find you have some time on your hands over the next few days! someone answered to that says that people that code *all* in asm has not need to speed programs
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2012-02-17 17:58 +0100 |
| Message-ID | <4f3e862d$0$1385$4fafbaef@reader2.news.tin.it> |
| In reply to | #14998 |
"io_x" <a@b.c.invalid> ha scritto nel messaggio news:4ef7fd4d$0$1389$4fafbaef@reader2.news.tin.it... > someone answered to that says > that people that code *all* in asm > has not need to speed programs than there is a better scaling for complexity too i would know it should be so i leave the question why to esperts...
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang.Draxinger" <Wolfgang.Draxinger@physik.uni-muenchen.de> |
|---|---|
| Date | 2012-01-10 18:00 +0100 |
| Message-ID | <20120110180034.21cd756e@gar-ws-bl08.garching.physik.uni-muenchen.de> |
| In reply to | #14925 |
On Fri, 23 Dec 2011 18:43:32 +0000 Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > I'm starting a new thread, but it is prompted by this remark from > 88888 Dihedral <dihedral88888@googlemail.com> about a short binary > search function I posted: > > | Do you consider to convert 5 to 10 lines of C to assembly? > | I did that 20 years ago on X86 cpu. > | It was a piece of cake to gain the 20-40% speed required if paid > | well. > > I've felt (it's only a feeling) that hand coding for speed (rather > than to access features not available in C like extra wide multiplies > and so on) was a thing of the past. But maybe I'm wrong. Is it > still possible to get a significant speed-up over C by hand coding? There are a few corner cases, where hand written assembly makes compiled code see only the rear lights. But those are few and far between. The problem is, that modern CPUs have so much side state, that it's next to impossible to keep track of all the little details, that may seem insignificant, but have a huge effect. Just the order of independent instruction blocks can have a large impact. However where hand written assembler is still useful is implementing the inner loops of complex algorithms processing (very) large datasets. Such algorithms usually involve only shuffling numbers around in a strict layout, so it's easy to reason about this kind of task and find patterns, that a compiler won't. And it allows to exploit peculiarities of the used instruction set, a compiler never could do. Like the one described by Dark Shikari here: http://stackoverflow.com/a/98251/524368 > How much depends on the processor? How good are the modern > optimising compilers that would have to be beaten? Depends on the task at hand. If it's just about the normal execution path of a program without many loops the compiler will most likely win, because will put the code in a lot of configurations through some simulation and count "clock cycles". Also there's s lot of heuristics in it. The other case are aforementioned processing loops. You as the algorithm, writer know about the dependencies in data access, know where pointers can possibly point and where not (the compiler doesn't), which allows to gain significant performance boosts in such situations. Wolfgang
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.c
csiph-web