Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #14925 > unrolled thread

Performance of hand-optimised assembly

Back to article view | Back to comp.lang.c

Contents

  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 1 of 6  [1] 2 3 4 5 6  Next page →

#14925 — Performance of hand-optimised assembly

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!

Here is a test program:

#include <stdio.h>
#include <stdlib.h>

size_t binsearch(int a[], size_t length, int key)
{
     size_t low = 0, high = length;
     while (high > low) {
          size_t middle = low + (high - low)/2;
          if (key == a[middle])
               return middle;
          else if (key > a[middle])
               low = middle + 1;
          else high = middle;
     }
     return -1;
}

#ifdef TIME_LOOP
#define binsearch(a, length, key) 1
#endif

int main(int argc, char **argv)
{
     if (argc == 2) {
          int n = atoi(argv[1]);
          /* cast so C++ compiled code can timed */
          int *data = (int *)malloc(n * sizeof *data);
          if (data) {
               int i, length, step, key;
               long int sum;
               for (i = 0; i < n; i++)
                    data[i] = 2 * i + 1;

               /* Include one zero-length search for correctness testing */
               sum = binsearch(data, 0, data[0]);
               for (length = 1; length <= n; length++)
                    for (step = 1; step <= length; step++)
                         for (key = 0; key <= 2 * length; key += step)
                              sum += binsearch(data, length, key);
               printf("%ld\n", sum);
               return EXIT_SUCCESS;
          }
     }
     return EXIT_FAILURE;
}

The pattern of calls it makes is not intended to be representative.  If
cache effects turn out to dominate, so be it -- this is a just for fun
after all.

On my laptop[1], gcc's optimiser (version 4.6.1) almost exactly halves the
times.  clang's code is a little better at -O0, but the optimised code
is a little worse:
                 -O0     -O1     -O2     -O3
  gcc         0.1128  0.0633  0.0571  0.0562
  g++         0.1167  0.0633  0.0572  0.0564
  clang       0.1033  0.0669  0.0672  0.0672

These times are microseconds per call.  The loop overhead has been
subtracted[2].  On a low-power chip[3] I get:

                 -O0     -O1     -O2     -O3
  gcc         0.7872  0.4296  0.4166  0.3688
  g++         0.7842  0.4290  0.4160  0.3688

which says nothing new (except how slow the CPU is).

What about other compilers and processors?  Can anyone produce code that
is significantly better than gcc -O3 by hand?  If you try, how long did
it take to get it both correct and faster?  Does your version handle the
same range of values as the C version?

[1] Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz, 3MB cache
[2] Crude timing script available on request.
[3] Geode(TM) Integrated Processor by AMD PCS, 500MHz, 128KB cache.
-- 
Ben.

[toc] | [next] | [standalone]

#14927

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:0.d0ecd8f477637819bed2.20111223184332GMT.87pqffjfhn.fsf@bsb.me.uk...

> int main(int argc, char **argv)
> {
>     if (argc == 2) {

What value of n (from argv) did you use for your test, and what was the 
output?

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#14930

"BartC" <bc@freeuk.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.d0ecd8f477637819bed2.20111223184332GMT.87pqffjfhn.fsf@bsb.me.uk...
>
>> int main(int argc, char **argv)
>> {
>>     if (argc == 2) {
>
> What value of n (from argv) did you use for your test, and what was
> the output?

1500 on the laptop and 700 on the slower machine.  The output was:

$ gcc -O2 btime.c
$ ./a.out 1500
2297638170

When compiled with -DTIME_LOOP, the output is the number of calls:

$ gcc -O2 -DTIME_LOOP btime.c
$ ./a.out 1500
17258078

which helps with calculating the time per call.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#14932

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:0.9694efe9cf80a723ba50.20111223212608GMT.87k45nj7yn.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:
>
>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>> news:0.d0ecd8f477637819bed2.20111223184332GMT.87pqffjfhn.fsf@bsb.me.uk...
>>
>>> int main(int argc, char **argv)
>>> {
>>>     if (argc == 2) {
>>
>> What value of n (from argv) did you use for your test, and what was
>> the output?
>
> 1500 on the laptop and 700 on the slower machine.  The output was:
>
> $ gcc -O2 btime.c
> $ ./a.out 1500
> 2297638170

That's odd; the output I get across 3 compilers (under Windows)
was -1997329126 (and using 'long long int sum' results in a totally
different result again).

Anyway, the results I got were as follows, with fastest/slowest times in
seconds, all for x86-32 under Windows (and all fairly old):

lcc-win32  1.4/1.8 (3.8 June 2010)
DMC        1.2/1.7 (Digital Mars 8.42n)
gcc        0.8/2.1 (Mingw 4.5.0, no special processor options used)

My first assembly version of the body of binsearch() took about 1.0 seconds;
pretty much anything else I tried, even taking out several instructions,
made it slower!

But then I'm not an expert on the internal workings of modern x86 
processors. Someone who is, I'm sure could at least have matched gcc.

Your example though is probably perfect material for a compiler optimiser to
work with: half-a-dozen variables which fit neatly into the half-dozen spare
registers on the x86! Not much scope left to improve on.

I do remember a few years ago implementing an interpreter in C, which had
been previously been written in a mix of high-level code plus lots of inline
assembly; the C code, even compiled under gcc, was half the speed (and my
assembly code then was probably just as poor as it is now). However
implementing languages is probably a special case..

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#14938

"BartC" <bc@freeuk.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.9694efe9cf80a723ba50.20111223212608GMT.87k45nj7yn.fsf@bsb.me.uk...
>> "BartC" <bc@freeuk.com> writes:
>>
>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>> news:0.d0ecd8f477637819bed2.20111223184332GMT.87pqffjfhn.fsf@bsb.me.uk...
>>>
>>>> int main(int argc, char **argv)
>>>> {
>>>>     if (argc == 2) {
>>>
>>> What value of n (from argv) did you use for your test, and what was
>>> the output?
>>
>> 1500 on the laptop and 700 on the slower machine.  The output was:
>>
>> $ gcc -O2 btime.c
>> $ ./a.out 1500
>> 2297638170
>
> That's odd; the output I get across 3 compilers (under Windows)
> was -1997329126 (and using 'long long int sum' results in a totally
> different result again).

Yes, sadly the result depends on the value of SIZE_MAX and the behaviour
of adding that to a long.  It won't affect timing but it does mean the
output is not portable.  Making binsearch return int rather than size_t
will, I think, fix that but it may alter the timing.  (It has only a tiny
effect on my system but I'd leave it alone none the less).

> Anyway, the results I got were as follows, with fastest/slowest times in
> seconds, all for x86-32 under Windows (and all fairly old):
>
> lcc-win32  1.4/1.8 (3.8 June 2010)
> DMC        1.2/1.7 (Digital Mars 8.42n)
> gcc        0.8/2.1 (Mingw 4.5.0, no special processor options used)

Is this variation due to optimised and unoptimised code?

> My first assembly version of the body of binsearch() took about 1.0 seconds;
> pretty much anything else I tried, even taking out several instructions,
> made it slower!

Well, it's not bad that you can beat 2 of the three compilers.

> But then I'm not an expert on the internal workings of modern x86
> processors. Someone who is, I'm sure could at least have matched gcc.
>
> Your example though is probably perfect material for a compiler optimiser to
> work with: half-a-dozen variables which fit neatly into the half-dozen spare
> registers on the x86! Not much scope left to improve on.

Yup.  That was what rather surprised me about the suggestion of
converting to assembler for speed.  It looked an unlikely candidate.

> I do remember a few years ago implementing an interpreter in C, which had
> been previously been written in a mix of high-level code plus lots of inline
> assembly; the C code, even compiled under gcc, was half the speed (and my
> assembly code then was probably just as poor as it is now). However
> implementing languages is probably a special case..

In some sense everything is a special case.  Language implementation is a
perfectly reasonably role for C, so there's no reason to discard such
data.  The trouble is that without code to review, it's impossible to
know where the speed was lost.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#14939

http://ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html

Check the site to combine C and assembly for GCC. 

[toc] | [prev] | [next] | [standalone]

#14958

"88888 Dihedral" <dihedral88888@googlemail.com> wrote in message 
news:11437228.11.1324701159954.JavaMail.geo-discussion-forums@prix23...
> http://ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html
>
> Check the site to combine C and assembly for GCC.

Having to use that ghastly AT&T syntax is an argument *against* using 
assembly, even if it is faster...

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#14963

On Dec 24, 1:09 pm, "BartC" <b...@freeuk.com> wrote:

...

> Having to use that ghastly AT&T syntax is an argument *against* using
> assembly, even if it is faster...

Agreed!

Can you give me any pointers on how to link gcc and nasm or another
separate assembler? I've found a few web references with useful tips
but IIRC one of them was your first attempt at this a few years ago.
Maybe you found some more info since then. I know I can do it but
maybe there are good ways and bad ways.

James

[toc] | [prev] | [next] | [standalone]

#14966

> Can you give me any pointers on how to link gcc and nasm or another
> separate assembler? I've found a few web references with useful tips
> but IIRC one of them was your first attempt at this a few years ago.
> Maybe you found some more info since then. I know I can do it but
> maybe there are good ways and bad ways.

I haven't made any more attempts since then. You still have the problem in
that the assembly code with the nice syntax has to be in a separate module,
not inline.

To combine, you probably know how; it means running Nasm with the right
object format (nasm -fwin32 under Windows), and presenting the resulting
.obj file to gcc in it's list of list of files.

Oh, and you have to put "_" in front any exported names in the asm module,
for some reason that I still don't know.

And you have to sort out calling conventions between the two languages (C 
calling Asm, and Asm calling C).

So it's still a bit fiddly.

(I normally use assembly as inline code within my own language. The
advantages are the use of Intel/Nasm syntax, with no need to write each line
as a string literal either, and being able to write substantial amounts of
code within a high-level language framework: functions, declarations, local
namespaces in each function, etc.

Also interaction with the high-level code is simple (optimisation doesn't
get in the way, for a start!). A lot of other issues are taken care of too.

I would call that a _good_ and easy way of using assembly. If anyone knows
of a C compiler that offers the same, then I might start using C a lot
more.)

-- 
bartc 

[toc] | [prev] | [next] | [standalone]

#14971

On Dec 24, 3:30 pm, "BartC" <b...@freeuk.com> wrote:

...

> To combine, you probably know how; it means running Nasm with the right
> object format (nasm -fwin32 under Windows), and presenting the resulting
> .obj file to gcc in it's list of list of files.
>
> Oh, and you have to put "_" in front any exported names in the asm module,
> for some reason that I still don't know.
>
> And you have to sort out calling conventions between the two languages (C
> calling Asm, and Asm calling C).
>
> So it's still a bit fiddly.

I'm aware there are various options for name mangling and parameter
passing. I'm just not sure which of the many are best, if there is
such a thing. I asked in response to Ben's initial post as you had got
a test working but I'm thinking this is too big an issue for this
subthread and needs a separate post, and a crosspost at that!
Something to come back to.

James

[toc] | [prev] | [next] | [standalone]

#14973

"James Harris" <james.harris.1@googlemail.com> wrote in message 
news:66cd7759-de68-49dd-b240-b218646b9051@n6g2000vbg.googlegroups.com...
> On Dec 24, 3:30 pm, "BartC" <b...@freeuk.com> wrote:

>> And you have to sort out calling conventions between the two languages (C
>> calling Asm, and Asm calling C).
>>
>> So it's still a bit fiddly.
>
> I'm aware there are various options for name mangling and parameter
> passing. I'm just not sure which of the many are best, if there is
> such a thing.

If you're interfacing with C, the possibilities for parameter passing are 
limited, usually you have to go along with what the specific C compiler 
does, or whatever foreign interfaces are supported.

Apparently for x86-64, parameters would be passed in registers, which is 
best for this example, but on x86-32, the stack seems to be favoured. In any 
case the 'winning entry' (gcc -O3) bypassed the whole issue by inlining the 
code (which I considered cheating).

> I asked in response to Ben's initial post as you had got
> a test working

The test proposed actually would have worked well written in a separate 
module, but I couldn't remember all the fiddly details I needed to know, and 
used inline assembly in a language I was familiar with.

> but I'm thinking this is too big an issue for this
> subthread and needs a separate post, and a crosspost at that!
> Something to come back to.

The bigger issue is not so much getting these things to work, as whether it 
is still worthwhile using assembly at all, in these days of 
'super-intelligent' compilers (which I haven't really come across myself). I 
think that was the point of the thread.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#14980

"BartC" <bc@freeuk.com> writes:
<snip>
>           In any case the 'winning entry' (gcc -O3) bypassed the whole
> issue by inlining the code (which I considered cheating).

That's an interesting point.  I think it would be enough to show that
"beating" gcc -O2 is both possible and worth-while, but inlining is a
tool available to compilers that is often not available to hand coders.
When it can be done, it's another point in favour of sticking to C and
relying on the compiler.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#15394

In article <0.e2de05187262c0a81453.20111224232506GMT.878vm1k0x9.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:

>I think it would be enough to show that
>"beating" gcc -O2 is both possible and worth-while, but inlining is a
>tool available to compilers that is often not available to hand coders.

It is 'available'; it may just not be the best use of time.  A C coder
can type i-n-l-i-n-e-space; a compiler can say 'this function is a part
of that function', 'apply the usual algorithms' and be done in ms; where
for a human coder it may be 'inline, no prob'; so then 'suppose that we
switch esi and edi in the called code, we can use -- trick, so it gains
one cycle'; 'suppose you do loop control by this trick'; so then few
days later 'suppose that we switch eax and ecx in the called code, we
can use -- trick', so it gains one cycle', and let me go to sleep.

[toc] | [prev] | [next] | [standalone]

#15401

Le 04/01/12 04:24, Joe keane a écrit :
> In article<0.e2de05187262c0a81453.20111224232506GMT.878vm1k0x9.fsf@bsb.me.uk>,
> Ben Bacarisse<ben.usenet@bsb.me.uk>  wrote:
>
>> I think it would be enough to show that
>> "beating" gcc -O2 is both possible and worth-while, but inlining is a
>> tool available to compilers that is often not available to hand coders.
>
> It is 'available'; it may just not be the best use of time.  A C coder
> can type i-n-l-i-n-e-space; a compiler can say 'this function is a part
> of that function', 'apply the usual algorithms' and be done in ms; where
> for a human coder it may be 'inline, no prob'; so then 'suppose that we
> switch esi and edi in the called code, we can use -- trick, so it gains
> one cycle'; 'suppose you do loop control by this trick'; so then few
> days later 'suppose that we switch eax and ecx in the called code, we
> can use -- trick', so it gains one cycle', and let me go to sleep.

Yes, that is a good idea. Go to sleep.

I am finishing the assembly language core of lcc-win for extended
precision floats (448 bits) for the Macintosh version. I used for
that assembly (x86) and it shines.

Rotating a series of values up or down for instance can be done in
assembly in a few instructions,but can't be done at all in C.

Using the carry in multi-precision operations is essential for
extended floating point. Impractical in C but easy on assembly.

Etc. But I see that you use "--- trick" in your prose, probably you
have never programmed in assembly and (like most people here)
are ust showing to the world your prejudices.

Go to sleep, its a good idea.

[toc] | [prev] | [next] | [standalone]

#15414

In article <je14cu$khs$1@speranza.aioe.org>,
jacob navia <jacob@jspamsink.org> wrote:
>probably you have never programmed in assembly

Excuse me sir, MACRO-11 was the first language i learned, after BASIC.

[toc] | [prev] | [next] | [standalone]

#15422

"jacob navia" <jacob@spamsink.net> wrote in message 
news:je14cu$khs$1@speranza.aioe.org...
> Le 04/01/12 04:24, Joe keane a écrit :

>> can use -- trick', so it gains one cycle', and let me go to sleep.
>
> Yes, that is a good idea. Go to sleep.
>
> I am finishing the assembly language core of lcc-win for extended
> precision floats (448 bits) for the Macintosh version. I used for
> that assembly (x86) and it shines.
>
> Rotating a series of values up or down for instance can be done in
> assembly in a few instructions,but can't be done at all in C.
>
> Using the carry in multi-precision operations is essential for
> extended floating point. Impractical in C but easy on assembly.

I'm sure it could be coded somehow in C. In that case, how much faster do 
you think the assembly version might be compared to C (even using the most 
advanced optimising compiler available)?

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#15463

James Harris wrote:

> Can you give me any pointers on how to link gcc and nasm or another
> separate assembler? I've found a few web references with useful tips
> but IIRC one of them was your first attempt at this a few years ago.
> Maybe you found some more info since then. I know I can do it but
> maybe there are good ways and bad ways.

comp.lang.asm.x86
alt.lang.asm

[toc] | [prev] | [next] | [standalone]

#14981

BartC wrote:
> Having to use that ghastly AT&T syntax is an argument *against* using 
> assembly, even if it is faster...

You can use the Intel syntax with gas. Use the pseudo-op
	.intel_syntax noprefix
You can even use it in gcc inline assembly--open each inline group with 
that and close with
	.att_syntax prefix
I only bother to do it for code groups with more than a few 
instructions.

[toc] | [prev] | [next] | [standalone]

#14955

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:0.393ac02b1554cc6fda1d.20111224025213GMT.87ehvuk7fm.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:

>> Anyway, the results I got were as follows, with fastest/slowest times in
>> seconds, all for x86-32 under Windows (and all fairly old):
>>
>> lcc-win32  1.4/1.8 (3.8 June 2010)
>> DMC        1.2/1.7 (Digital Mars 8.42n)
>> gcc        0.8/2.1 (Mingw 4.5.0, no special processor options used)
>
> Is this variation due to optimised and unoptimised code?

Yes. Either using -O/-o for the first two, or not using it; and using -O3
or -O0 for gcc.

>> My first assembly version of the body of binsearch() took about 1.0
>> seconds;
>> pretty much anything else I tried, even taking out several instructions,
>> made it slower!
>
> Well, it's not bad that you can beat 2 of the three compilers.

lcc-win32 is not known for it's fast code, so that wasn't so surprising.
Looking at the fast gcc result in more detail, it eliminates the first call
to binsearch() completely (but doesn't save so much because it doesn't enter
the loop), and inlines the second call.

If I did the same in assembly, and partially unrolled the loop (fiddly in
this case), I got to within 50ms of the gcc timing. (My assembly code was
inside a version in my own language and my own non-optimising compiler, so
probably the rest of the code makes the difference. FWIW the timing in that
high-level code would have been about 2.1 seconds).

So for this example, I don't think gcc was demonstrating any special
knowledge of my processor; maybe there are processor-specific switches that
could have been used. But it would be interesting to know the results for an
compiler like Intel's (or rather, AMD's, if they do a compiler, since that's
what my machine uses).

>> Your example though is probably perfect material for a compiler optimiser
>> to
>> work with: half-a-dozen variables which fit neatly into the half-dozen
>> spare
>> registers on the x86! Not much scope left to improve on.
>
> Yup.  That was what rather surprised me about the suggestion of
> converting to assembler for speed.  It looked an unlikely candidate.

It all depends. If this wasn't just an array of standard machine words, or
there was some other unusual context, then there are more coding
possibilities and perhaps more opportunities to improve on the compiler.

> However
>> implementing languages is probably a special case..
>
> In some sense everything is a special case.  Language implementation is a
> perfectly reasonably role for C, so there's no reason to discard such
> data.  The trouble is that without code to review, it's impossible to
> know where the speed was lost.

In this example, I was making global decisions not easily available to a C
compiler, such as choosing to use some dedicated registers across a specific
set of 'conforming' functions, which comprised the main dispatch loop of
this interpreter (namely, program counter, frame pointer, and stack
pointer). I needed to save and restore those registers when stepping out of,
and back into, those conforming functions.

I was also using threaded code for these functions (jumping from the end of
one function, to the start of the next, with no call/return mechanism). Now
gcc has a mechanism for threaded code via indirect labels, but seems
restricted to labels within the one function, but I didn't really want a
single 10,000-line function.

And in a more recent version, I'm using one dedicated register, but making
use of the *hardware* stack and frame pointers, by using the system stack
for the interpreter's data stack. Now I'm sure you can't just tell C to push 
or pop some arbitrary data to the stack, then carry on as normal! (And since 
this is 50% faster, the straight-C version may well have been 1/3 the 
speed.)

So I think language applications *are* somewhat more special.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#14968

Hello,

Am 12/24/2011 01:42 PM, schrieb BartC:
> Yes. Either using -O/-o for the first two, or not using it; and using -O3
> or -O0 for gcc.
> ...
> So for this example, I don't think gcc was demonstrating any special
> knowledge of my processor; maybe there are processor-specific switches that
> could have been used.

with modern gcc you can always use -march=native to optimize for the
processor on which the compiler is running

Jens

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web