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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-12-21 21:41 +0000 |
| Message-ID | <0.4b8c1cc5fedd08ec9708.20111221214133GMT.87r4zxmwky.fsf@bsb.me.uk> |
| In reply to | #14833 |
88888 Dihedral <dihedral88888@googlemail.com> writes:
> int binsearch ( int a[], int length, int key)
> {
> register int lo=0;
> register int hi=length-1;
> register int gap=hi-lo;
> register mid=lo+ (gap>>1);
Implicit int was removed from C99. Even if you prefer the older
standard it's not a very good idea to use it.
> //
>
> while(gap) // gap==0 then lo==hi==mid
> {
> if (key== a[mid] ) { return mid;}
> else if (key >a[mid]) { lo=mid;}
> else { hi=mid; }
>
> gap= hi-lo; mid=lo+(gap>>1);
>
> }
Your loop is not guaranteed to terminate.
> //gap ==0
> if (key==a[hi]) return hi; else return -1;
>
> //return the 32 bit or 64 bit integer
>
> }
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2011-12-21 16:35 -0800 |
| Message-ID | <28271069.79.1324514157943.JavaMail.geo-discussion-forums@prdv33> |
| In reply to | #14839 |
On Thursday, December 22, 2011 5:41:33 AM UTC+8, Ben Bacarisse wrote:
> 88888 Dihedral <dihedr...@googlemail.com> writes:
>
> > int binsearch ( int a[], int length, int key)
> > {
> > register int lo=0;
> > register int hi=length-1;
> > register int gap=hi-lo;
> > register mid=lo+ (gap>>1);
>
> Implicit int was removed from C99. Even if you prefer the older
> standard it's not a very good idea to use it.
>
> > //
> >
> > while(gap) // gap==0 then lo==hi==mid
> > {
> > if (key== a[mid] ) { return mid;}
> > else if (key >a[mid]) { lo=mid;}
> > else { hi=mid; }
> >
> > gap= hi-lo; mid=lo+(gap>>1);
> >
> > }
>
> Your loop is not guaranteed to terminate.
>
> > //gap ==0
> > if (key==a[hi]) return hi; else return -1;
> >
> > //return the 32 bit or 64 bit integer
> >
> > }
>
> --
> Ben.
Add gap>1 in the while
and else if (key==a[lo]) return lo; // outside the loop
What else can you suggest?
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-12-22 01:03 +0000 |
| Message-ID | <slrnjf50em.tcm.usenet-nospam@guild.seebs.net> |
| In reply to | #14844 |
On 2011-12-22, 88888 Dihedral <dihedral88888@googlemail.com> wrote: > What else can you suggest? I would suggest starting over from scratch, and learning about style, layout, and maintenance of code. As is, while that's not the worst code I've seen today, this is only because of a hilarious coincidence. -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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-12-22 03:19 +0000 |
| Message-ID | <0.f11c74e6cc5bf465d9c4.20111222031918GMT.87hb0tmgy1.fsf@bsb.me.uk> |
| In reply to | #14844 |
88888 Dihedral <dihedral88888@googlemail.com> writes:
> On Thursday, December 22, 2011 5:41:33 AM UTC+8, Ben Bacarisse wrote:
>> 88888 Dihedral <dihedr...@googlemail.com> writes:
>>
>> > int binsearch ( int a[], int length, int key)
>> > {
>> > register int lo=0;
>> > register int hi=length-1;
>> > register int gap=hi-lo;
>> > register mid=lo+ (gap>>1);
>>
>> Implicit int was removed from C99. Even if you prefer the older
>> standard it's not a very good idea to use it.
>>
>> > //
>> >
>> > while(gap) // gap==0 then lo==hi==mid
>> > {
>> > if (key== a[mid] ) { return mid;}
>> > else if (key >a[mid]) { lo=mid;}
>> > else { hi=mid; }
>> >
>> > gap= hi-lo; mid=lo+(gap>>1);
>> >
>> > }
>>
>> Your loop is not guaranteed to terminate.
>>
>> > //gap ==0
>> > if (key==a[hi]) return hi; else return -1;
>> >
>> > //return the 32 bit or 64 bit integer
>> >
>> > }
>>
>> --
>> Ben.
>
> Add gap>1 in the while
>
> and else if (key==a[lo]) return lo; // outside the loop
>
> What else can you suggest?
I'd (a) use size_t for the indexes and length, (b) tidy up the layout,
(c) keep all the testing in one place:
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;
}
The loop invariant is that the key's index (if it exists) is in [low,
high) i.e. low <= index < high. These asymmetric bounds avoid any
problems with unsigned indexes when length == 0. They also explain the
different settings for low and high.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2011-12-22 07:11 -0800 |
| Message-ID | <9453445.440.1324566701765.JavaMail.geo-discussion-forums@prez5> |
| In reply to | #14846 |
On Thursday, December 22, 2011 11:19:18 AM UTC+8, Ben Bacarisse wrote:
> 88888 Dihedral <dihedr...@googlemail.com> writes:
>
> > On Thursday, December 22, 2011 5:41:33 AM UTC+8, Ben Bacarisse wrote:
> >> 88888 Dihedral <dihe...@googlemail.com> writes:
> >>
> >> > int binsearch ( int a[], int length, int key)
> >> > {
> >> > register int lo=0;
> >> > register int hi=length-1;
> >> > register int gap=hi-lo;
> >> > register mid=lo+ (gap>>1);
> >>
> >> Implicit int was removed from C99. Even if you prefer the older
> >> standard it's not a very good idea to use it.
> >>
> >> > //
> >> >
> >> > while(gap) // gap==0 then lo==hi==mid
> >> > {
> >> > if (key== a[mid] ) { return mid;}
> >> > else if (key >a[mid]) { lo=mid;}
> >> > else { hi=mid; }
> >> >
> >> > gap= hi-lo; mid=lo+(gap>>1);
> >> >
> >> > }
> >>
> >> Your loop is not guaranteed to terminate.
> >>
> >> > //gap ==0
> >> > if (key==a[hi]) return hi; else return -1;
> >> >
> >> > //return the 32 bit or 64 bit integer
> >> >
> >> > }
> >>
> >> --
> >> Ben.
> >
> > Add gap>1 in the while
> >
> > and else if (key==a[lo]) return lo; // outside the loop
> >
> > What else can you suggest?
>
> I'd (a) use size_t for the indexes and length, (b) tidy up the layout,
> (c) keep all the testing in one place:
>
> 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;
> }
>
> The loop invariant is that the key's index (if it exists) is in [low,
> high) i.e. low <= index < high. These asymmetric bounds avoid any
> problems with unsigned indexes when length == 0. They also explain the
> different settings for low and high.
>
> --
> Ben.
Do you consider to convert 5 to 10 lines of C to assembly?
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-12-22 16:59 +0000 |
| Message-ID | <slrnjf6ocv.1rti.usenet-nospam@guild.seebs.net> |
| In reply to | #14864 |
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. 2. It eliminates portability. 3. It takes time. 4. It is very unlikely to produce a measurable benefit. When you're about to pop out to the store, do you take your car's fuel system apart and rebuild the carburetor? If so, why do you do this given that the vast majority of modern cars don't even have one? -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 | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-12-22 18:38 +0100 |
| Message-ID | <4ef36a30$0$1378$4fafbaef@reader2.news.tin.it> |
| In reply to | #14866 |
"Seebs" <usenet-nospam@seebs.net> ha scritto nel messaggio 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. > 2. It eliminates portability. > 3. It takes time. > 4. It is very unlikely to produce a measurable benefit. i have just one argument against yours: all code going out from one assembly programmer is from 10 to 1000 times better the one not know assembly this is only what i think one can not be sure of all and has to syntesis his results > When you're about to pop out to the store, do you take your car's fuel > system apart and rebuild the carburetor? If so, why do you do this given > that the vast majority of modern cars don't even have one? > > -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 | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2011-12-22 10:40 -0800 |
| Message-ID | <9452836.506.1324579210430.JavaMail.geo-discussion-forums@preg20> |
| In reply to | #14869 |
Are you saying that you are not good enough to write a compiler and help the GNU GCC projects?
[toc] | [prev] | [next] | [standalone]
| From | Markus Wichmann <nullplan@gmx.net> |
|---|---|
| Date | 2011-12-22 19:12 +0100 |
| Message-ID | <9h8cs8-4n8.ln1@voyager.wichi.de.vu> |
| In reply to | #14869 |
On 22.12.2011 18:38, io_x wrote: > "Seebs" <usenet-nospam@seebs.net> ha scritto nel messaggio > 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. >> 2. It eliminates portability. >> 3. It takes time. >> 4. It is very unlikely to produce a measurable benefit. > > i have just one argument against yours: > all code going out from one assembly programmer is from 10 > to 1000 times better the one not know assembly > this is only what i think > one can not be sure of all and has to syntesis his results > You really ought to try out a compiler from this century. Compilers are in general worse than competent assembly hand crafters, but not in that order of magnitude. Compiler-generated code has most of the time at most twice the run-time of the best known assembly code. That's if you write your C code to actually describe the algorithm you meant. Just saying. I've seen assembly advocates comparing apples to oranges on that question. (And then complain that the oranges don't taste as sweet.) If you need pointers: Try the current gcc, llvm or possibly dragonegg. HTH, Markus
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-12-28 03:50 -0800 |
| Message-ID | <916c68cc-1773-45b6-b400-7e39a69ce055@h3g2000yqa.googlegroups.com> |
| In reply to | #14869 |
On Dec 22, 5:38 pm, "io_x" <a...@b.c.invalid> wrote: > "Seebs" <usenet-nos...@seebs.net> ha scritto nel messaggionews:slrnjf6ocv.1rti.usenet-nospam@guild.seebs.net... > > On 2011-12-22, 88888 Dihedral <dihedral88...@googlemail.com> wrote: > >> Do you consider to convert 5 to 10 lines of C to assembly? did you mean "would you consider it sensible to convert 5 to 10 lines of C into assembly?". It would rather depend on the lines of C. How fast does it need to be? Is it fast enough? Would recoding it in assembler make any difference (likely not)? I think it very unlikely that the vast majority of C code would benefit in anyway from this. It's just a way to waste time and degrades the quality of your code. > > Of course not. > > > 1. It's a great way to introduce errors and bugs. > > 2. It eliminates portability. > > 3. It takes time. > > 4. It is very unlikely to produce a measurable benefit. > > i have just one argument against yours: > all code going out from one assembly programmer is from 10 > to 1000 times better the one not know assembly cite. Produce figures. You are mistaken. > this is only what i think so you just made that up? All assembler programs can run faster than any Olympic athelete. I just think this is so, I have never seen an assembler programmer run anywhere. > one can not be sure of all and has to syntesis his results please repost in a known language <snip>
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-12-28 17:06 +0100 |
| Message-ID | <4efb3da8$0$1389$4fafbaef@reader1.news.tin.it> |
| In reply to | #15097 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:916c68cc-1773-45b6-b400-7e39a69ce055@h3g2000yqa.googlegroups.com...
On Dec 22, 5:38 pm, "io_x" <a...@b.c.invalid> wrote:
> "Seebs" <usenet-nos...@seebs.net> ha scritto nel
> messaggionews:slrnjf6ocv.1rti.usenet-nospam@guild.seebs.net...
> > On 2011-12-22, 88888 Dihedral <dihedral88...@googlemail.com> wrote:
> >> Do you consider to convert 5 to 10 lines of C to assembly?
did you mean "would you consider it sensible to convert 5 to 10 lines
of C into assembly?". It would rather depend on the lines of C. How
fast does it need to be? Is it fast enough? Would recoding it in
assembler make any difference (likely not)? I think it very unlikely
that the vast majority of C code would benefit in anyway from this.
It's just a way to waste time and degrades the quality of your code.
> > Of course not.
>
> > 1. It's a great way to introduce errors and bugs.
> > 2. It eliminates portability.
> > 3. It takes time.
> > 4. It is very unlikely to produce a measurable benefit.
>
> i have just one argument against yours:
> all code going out from one assembly programmer is from 10
> to 1000 times better the one not know assembly
cite. Produce figures. You are mistaken.
#i'm right
#for example this:
#i don't had the time full test it,
#for example one has to try that for double , long double etc
#you can write that in C or in assembly, your bsearch() can be faster
#but my error detectrion is better of yours bsearch()
; would be like the C *library* bserach() function, with the only
; difference return (u8*)-1 for error
; return (u8*)-1 error, 0 not found, address of the found element in array
; if return 0 [not found]
; in ecx return the address element of the array < than key if exist
; else ecx=0
; in edx return the address element of the array > than key if exist
; else edx=0
;u8* __stdcall
;binSearchR(u8* InPKey, u8* InBase,
; u32 nElmBase, u32 SizeElmBase, i32 cmp(const u8* elm1, const u8*
elm2) );
; 0k,4j,8i,12b,16ra, 20InKey,24InBase,28P_nElmBase,32P_SizeElmBase,36P_cmp + 64
; 84 88 92 96 100
align 4
bsearch:
push ebx
push esi
push edi
push ebp
sub esp, 64
;int3
mov dword[esp+ 4], 0
mov dword[esp+ 8], 0
; in ^4 and ^8 thre is the last element > and <
cmp dword[esp+ 84], 0
je .e
cmp dword[esp+ 88], 0
je .e
mov edi, dword[esp+ 92]
mov ebx, dword[esp+ 100]
cmp dword[esp+ 96], 0
jle .e
cmp edi, 0
je .nf
mov esi, 0
jl .e
cmp ebx, 0
je .e
dec edi
jmp short .2
.nf: xor eax, eax
clc
jmp short .z
.e: xor eax, eax
dec eax
stc
jmp short .z
.2: cmp esi, edi
jg .nf
mov ebp, esi
add ebp, edi
shr ebp, 1 ; k=(i+j)/2
mov eax, dword[esp+ 96]
mul ebp
mov ecx, dword[esp+ 84]
cmp edx, 0
jne .e
add eax, dword[esp+ 88]
jc .e
mov dword[esp+ 0], eax
push ecx
push eax
call ebx
add esp, 8
cmp eax, 0
jle .3
dec ebp
mov ecx, dword[esp+ 0]
mov edi, ebp
mov dword[esp+ 4], ecx
jmp short .2
.3: jz .4
inc ebp
mov ecx, dword[esp+ 0]
mov esi, ebp
mov dword[esp+ 8], ecx
jmp short .2
.4: mov eax, dword[esp+ 0]
clc
.z: mov edx, dword[esp+ 4]
mov ecx, dword[esp+ 8]
lea esp, [esp+64]
pop ebp
pop edi
pop esi
pop ebx
ret 20
> this is only what i think
so you just made that up? All assembler programs can run faster than
any Olympic athelete. I just think this is so, I have never seen an
assembler programmer run anywhere.
#here they run: the only big error old assembly programmers
#is not consider one function can fail and make visible-corregible
#errors meet
> one can not be sure of all and has to syntesis his results
please repost in a known language
#it is pure NASM x86 pentium 32 bits
<snip>
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2012-01-01 20:04 +0100 |
| Message-ID | <4f00ad42$0$1383$4fafbaef@reader2.news.tin.it> |
| In reply to | #15119 |
"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:4efb3da8$0$1389$4fafbaef@reader1.news.tin.it...
> #i'm right
> #for example this:
> #i don't had the time full test it,
> #for example one has to try that for double , long double etc
> #you can write that in C or in assembly, your bsearch() can be faster
> #but my error detectrion is better of yours bsearch()
i test it against double [64 bit double] too and for luck it send to stdout
the right output [afther some debug and some time to search the error
in the compare functions...]
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#define d64 double
#define u32 unsigned
#define i32 int
#define u8 unsigned char
#define R return
#define P printf
#define F for
// const, how is smart...
#define cn const
/*
;return (u8*)-1 error, 0 not found, address of the found element in array
;if return 0 [not found]
; in ecx return the address element of the array < than key if exist
; else ecx=0
; in edx return the address element of the array > than key if exist
; else edx=0
would be like the C library one, with the only difference return (u8*)-1 for
error
*/
u8* __stdcall
binSearchR(u8* InPKey, u8* InBase, u32 nElmBase, u32 SizeElmBase,
i32 cmp(cn u8* elm1, cn u8* elm2) );
u32 __stdcall ReturnEcx(void);
u32 __stdcall ReturnEdx(void);
i32 __stdcall binsearch(int a[], size_t length, int key);
i32 Cbinsearch(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;
}
i32 cmpu32s(const u8* elm1, const u8* elm2)
{u32 m1, m2;
m1=*(u32*)elm1; m2=*(u32*)elm2;
if(m1<m2) R -1;
else if(m1>m2) R 1;
else R 0;
}
i32 cmpd64s(const u8* elm1, const u8* elm2)
{d64 m1, m2;
m1=*(d64*)elm1; m2=*(d64*)elm2;
/*
some time to find what was wrong
and the wrong were in the
m1=*(u32*)elm1; m2=*(u32*)elm2;
i wrong copy
*/
if(m1<m2) R -1;
else if(m1>m2) R 1;
else R 0;
}
int main(int argc, char** argv)
{time_t in, fin;
double d, dval=4, id;
i32 v[]={1, 2, 5, 7, 8, 8, 9, 13, 20};
d64 vd[]={1, 2, 5, 7, 8, 8, 9, 13, 20};
u32 val=4, *w, *ww, i;
i32 ix, ixx;
u8 *r;
F(i=0; i<9; ++i)
{if(i!=8) P("%u, ", v[i]);
else P("%u\n", v[i]);
}
F(i=0; i<9; ++i)
{if(i!=8) P("%f, ", vd[i]);
else P("%f\n", vd[i]);
}
F(i=0; i<23; ++i)
{r=binSearchR((u8*) &i, (u8*) v, 9, sizeof(u32), cmpu32s);
w=(u32*) ReturnEcx(); ww=(u32*) ReturnEdx();
if(r!=0) P("For %u r=%p find=%u\n", i, (void*)r, *(u32*)r);
else {P("For %u ", i);
if(w!=0) P("w =%p find=%u- ", (void*)w, *(u32*)w);
else P("w = 0- ");
if(ww!=0) P("ww=%p find=%u+ ", (void*)ww, *(u32*)ww);
else P("ww= 0+ ");
P("\n");
}
}
/*
F(i=0; i<23; ++i)
{ix =binsearch((i32*) v, 9, i);
P("For %u FindIndx=%d\n", i, ix);
ixx=Cbinsearch((i32*) v, 9, i);
if(ixx!=ix) P("\nError index %u\n", i);
}
*/
F(id=0; id<23; ++id)
{r=binSearchR((u8*) &id, (u8*) vd, 9, sizeof(d64), cmpd64s);
w=(u32*) ReturnEcx(); ww=(u32*) ReturnEdx();
if(r!=0) P("For %.1f r=%p find=%.1f\n", id, (void*)r, d=*(d64*)r);
else {P("For %.1f ", id);
if(w!=0) P("w =%p find=%.1f- ", (void*)w, d=*(d64*)w);
else P("w = 0- ");
if(ww!=0) P("ww=%p find=%.1f+ ", (void*)ww, d=*(d64*)ww);
else P("ww= 0+ ");
P("\n");
}
}
R 0;
}
--------------------------------
1, 2, 5, 7, 8, 8, 9, 13, 20
1.000000, 2.000000, 5.000000, 7.000000, 8.000000, 8.000000, 9.000000, 13.0000
For 0 w = 0- ww=0012FF50 find=1+
For 1 r=0012FF50 find=1
For 2 r=0012FF54 find=2
For 3 w =0012FF54 find=2- ww=0012FF58 find=5+
For 4 w =0012FF54 find=2- ww=0012FF58 find=5+
For 5 r=0012FF58 find=5
For 6 w =0012FF58 find=5- ww=0012FF5C find=7+
For 7 r=0012FF5C find=7
For 8 r=0012FF60 find=8
For 9 r=0012FF68 find=9
For 10 w =0012FF68 find=9- ww=0012FF6C find=13+
For 11 w =0012FF68 find=9- ww=0012FF6C find=13+
For 12 w =0012FF68 find=9- ww=0012FF6C find=13+
For 13 r=0012FF6C find=13
For 14 w =0012FF6C find=13- ww=0012FF70 find=20+
For 15 w =0012FF6C find=13- ww=0012FF70 find=20+
For 16 w =0012FF6C find=13- ww=0012FF70 find=20+
For 17 w =0012FF6C find=13- ww=0012FF70 find=20+
For 18 w =0012FF6C find=13- ww=0012FF70 find=20+
For 19 w =0012FF6C find=13- ww=0012FF70 find=20+
For 20 r=0012FF70 find=20
For 21 w =0012FF70 find=20- ww= 0+
For 22 w =0012FF70 find=20- ww= 0+
For 0.0 w = 0- ww=0012FF08 find=1.0+
For 1.0 r=0012FF08 find=1.0
For 2.0 r=0012FF10 find=2.0
For 3.0 w =0012FF10 find=2.0- ww=0012FF18 find=5.0+
For 4.0 w =0012FF10 find=2.0- ww=0012FF18 find=5.0+
For 5.0 r=0012FF18 find=5.0
For 6.0 w =0012FF18 find=5.0- ww=0012FF20 find=7.0+
For 7.0 r=0012FF20 find=7.0
For 8.0 r=0012FF28 find=8.0
For 9.0 r=0012FF38 find=9.0
For 10.0 w =0012FF38 find=9.0- ww=0012FF40 find=13.0+
For 11.0 w =0012FF38 find=9.0- ww=0012FF40 find=13.0+
For 12.0 w =0012FF38 find=9.0- ww=0012FF40 find=13.0+
For 13.0 r=0012FF40 find=13.0
For 14.0 w =0012FF40 find=13.0- ww=0012FF48 find=20.0+
For 15.0 w =0012FF40 find=13.0- ww=0012FF48 find=20.0+
For 16.0 w =0012FF40 find=13.0- ww=0012FF48 find=20.0+
For 17.0 w =0012FF40 find=13.0- ww=0012FF48 find=20.0+
For 18.0 w =0012FF40 find=13.0- ww=0012FF48 find=20.0+
For 19.0 w =0012FF40 find=13.0- ww=0012FF48 find=20.0+
For 20.0 r=0012FF48 find=20.0
For 21.0 w =0012FF48 find=20.0- ww= 0+
For 22.0 w =0012FF48 find=20.0- ww= 0+
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-01-01 12:38 -0800 |
| Message-ID | <6be77116-b479-4cbe-a0c6-c694ae256160@f33g2000yqh.googlegroups.com> |
| In reply to | #15270 |
On Jan 1, 7:04 pm, "io_x" <a...@b.c.invalid> wrote: > "io_x" <a...@b.c.invalid> ha scritto nel messaggionews:4efb3da8$0$1389$4fafbaef@reader1.news.tin.it... > > > #i'm right > > #for example this: > > #i don't had the time full test it, > > #for example one has to try that for double , long double etc > > #you can write that in C or in assembly, your bsearch() can be faster > > #but my error detectrion is better of yours bsearch() > > i test it against double [64 bit double] too and for luck it send to stdout > the right output [afther some debug and some time to search the error > in the compare functions...] > > #include <stdio.h> > #include <stdlib.h> > #include <time.h> > #define d64 double > #define u32 unsigned > #define i32 int as I've noted before I don't read code like this <snip horrid C> so what does your program do? Is it a binary search written in (what you call) C? > -------------------------------- > 1, 2, 5, 7, 8, 8, 9, 13, 20 > 1.000000, 2.000000, 5.000000, 7.000000, 8.000000, 8.000000, 9.000000, 13.0000 > > For 0 w = 0- ww=0012FF50 find=1+ > For 1 r=0012FF50 find=1 > For 2 r=0012FF54 find=2 <snip more of same> and what does it mean? Have you shown your assembler is 1000 times faster than your C? Or 1000 times faster than my C?
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2012-01-02 10:14 +0100 |
| Message-ID | <4f0174a1$0$1388$4fafbaef@reader2.news.tin.it> |
| In reply to | #15276 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio news:6be77116-b479-4cbe-a0c6-c694ae256160@f33g2000yqh.googlegroups.com... On Jan 1, 7:04 pm, "io_x" <a...@b.c.invalid> wrote: > "io_x" <a...@b.c.invalid> ha scritto nel > messaggionews:4efb3da8$0$1389$4fafbaef@reader1.news.tin.it... > > > #i'm right > > #for example this: > > #i don't had the time full test it, > > #for example one has to try that for double , long double etc > > #you can write that in C or in assembly, your bsearch() can be faster > > #but my error detectrion is better of yours bsearch() > > i test it against double [64 bit double] too and for luck it send to stdout > the right output [afther some debug and some time to search the error > in the compare functions...] > > #include <stdio.h> > #include <stdlib.h> > #include <time.h> > #define d64 double > #define u32 unsigned > #define i32 int as I've noted before I don't read code like this <snip horrid C> #it is the way C has to behavie so what does your program do? Is it a binary search written in (what you call) C? > -------------------------------- > 1, 2, 5, 7, 8, 8, 9, 13, 20 > 1.000000, 2.000000, 5.000000, 7.000000, 8.000000, 8.000000, 9.000000, 13.0000 > > For 0 w = 0- ww=0012FF50 find=1+ > For 1 r=0012FF50 find=1 > For 2 r=0012FF54 find=2 <snip more of same> and what does it mean? Have you shown your assembler is 1000 times faster than your C? Or 1000 times faster than my C? #it is 10 times safer than your C version #asm safer... people would laught on that #a binsearch algo something as O(log(n)) can not be the bottle neck #right?
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-01-03 04:56 -0800 |
| Message-ID | <f22ddb6f-9fe8-49db-ab29-2f85ea8f5efd@z12g2000yqm.googlegroups.com> |
| In reply to | #15304 |
On Jan 2, 9:14 am, "io_x" <a...@b.c.invalid> wrote: > "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:6be77116-b479-4cbe-a0c6-c694ae256160@f33g2000yqh.googlegroups.com... > On Jan 1, 7:04 pm, "io_x" <a...@b.c.invalid> wrote: > > > > > > > "io_x" <a...@b.c.invalid> ha scritto nel > > messaggionews:4efb3da8$0$1389$4fafbaef@reader1.news.tin.it... > > > > #i'm right > > > #for example this: > > > #i don't had the time full test it, > > > #for example one has to try that for double , long double etc > > > #you can write that in C or in assembly, your bsearch() can be faster > > > #but my error detectrion is better of yours bsearch() > > > i test it against double [64 bit double] too and for luck it send to stdout > > the right output [afther some debug and some time to search the error > > in the compare functions...] > > > #include <stdio.h> > > #include <stdlib.h> > > #include <time.h> > > #define d64 double > > #define u32 unsigned > > #define i32 int > > as I've noted before I don't read code like this actually I meant code like /this/ #define R return #define P printf #define F for > <snip horrid C> > #it is the way C has to behavie no, it's your bizzare way of coding. Write in a sensible style and I'll read it. > so what does your program do? Is it a binary search written in (what > you call) C? hello? > > 1, 2, 5, 7, 8, 8, 9, 13, 20 > > 1.000000, 2.000000, 5.000000, 7.000000, 8.000000, 8.000000, 9.000000, 13.0000 > > > For 0 w = 0- ww=0012FF50 find=1+ > > For 1 r=0012FF50 find=1 > > For 2 r=0012FF54 find=2 > > <snip more of same> > > and what does it mean? Have you shown your assembler is 1000 times > faster than your C? Or 1000 times faster than my C? > > #it is 10 times safer than your C version well since I havn't shown you any code I don't know how you can tell this. How do you measure safety? In what sense is your code 10 times "safer" tahn typical C. You claimed you could write asssmbler that was 10 to 1000 times faster than typical C. I think you were mistaken (I thought of a ruder word) > #asm safer... people would laught on that so you've dropped the faster claim? > #a binsearch algo something as O(log(n)) can not be the bottle neck > #right?- could be if you had to search a lot of data
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2012-01-03 18:26 +0100 |
| Message-ID | <4f03396a$0$1387$4fafbaef@reader2.news.tin.it> |
| In reply to | #15368 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:f22ddb6f-9fe8-49db-ab29-2f85ea8f5efd@z12g2000yqm.googlegroups.com...
On Jan 2, 9:14 am, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel
> messaggionews:6be77116-b479-> > > #i'm right
> > > #for example this:
> > > #i don't had the time full test it,
> > > #for example one has to try that for double , long double etc
> > > #you can write that in C or in assembly, your bsearch() can be faster
> > > #but my error detectrion is better of yours bsearch()
>
> > i test it against double [64 bit double] too and for luck it send to stdout
> > the right output [afther some debug and some time to search the error
> > in the compare functions...]
>
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <time.h>
> > #define d64 double
> > #define u32 unsigned
> > #define i32 int
>
> as I've noted before I don't read code like this
actually I meant code like /this/
#define R return
#define P printf
#define F for
> <snip horrid C>
> #it is the way C has to behavie
no, it's your bizzare way of coding. Write in a sensible style and
I'll read it.
#for the test C code:
#it is standard C, there are only some macro
#possibly you want follow only your programming style...
#only the test program is written in the C
#the routine bin-search, what i here speak about
#is written using my .asm type language:
#; return (u8*)-1 error, 0 not found, address of the found element in array
#; if return 0 [not found]
#; in ecx return the address element of the array < than key if exist
#; else ecx=0
#; in edx return the address element of the array > than key if exist
#; else edx=0
#; would be like the C library one, with the only difference return (u8*)-1 for
error
#;u8* __stdcall
#;binSearchR(u8* InPKey, u8* InBase,
#; u32 nElmBase, u32 SizeElmBase, i32 cmp(u8* elm1, u8* elm2) );
#; 0k,4j,8i,12b,16ra, 20InKey,24InBase,28P_nElmBase,32P_SizeElmBase,36P_cmp + 64
#; 84 88 92 96 100
#align 4
#binSearchR:
#<b,i,j,k
#s-=64
# ;int3
# ^4=0|^8=0 ; in ^4 and ^8 thre is the last element > and <
# ^84==0#.e|^88==0#.e |j=^92|b=^100|^96<=0?#.e
# j==0#.nf |i=0 |<?#.e|b==0#.e|--j|#.2
#.nf: a^=a |clc|#.z
#.e: a^=a|--a|stc|#.z
#.2: i>j?#.nf|k=i|k+=j|k>>=1 ; k=(i+j)/2
# a=^96|mul k|c=^84|r#.e|a+=^88|jc .e|^0=a
# b<(a,c) |a>0!?#.3|--k |c=^0|j=k|^4=c|#.2
#.3: =#.4|++k |c=^0|i=k|^8=c|#.2
#.4: a=^0|clc
#.z: r=^4|c=^8
#s=&*s+64
#>b,i,j,k
#ret 20
#the traslation for x86 cpu Nasm would be someting as:
align 4
binSearchR:
push ebx
push esi
push edi
push ebp
sub esp, 64
;int3
mov dword[esp+ 4], 0
mov dword[esp+ 8], 0
; in ^4 and ^8 thre is the last element > and <
cmp dword[esp+ 84], 0
je .e
cmp dword[esp+ 88], 0
je .e
mov edi, dword[esp+ 92]
mov ebx, dword[esp+ 100]
cmp dword[esp+ 96], 0
jle .e
cmp edi, 0
je .nf
mov esi, 0
jl .e
cmp ebx, 0
je .e
dec edi
jmp short .2
.nf: xor eax, eax
clc
jmp short .z
.e: xor eax, eax
dec eax
stc
jmp short .z
.2: cmp esi, edi
jg .nf
mov ebp, esi
add ebp, edi
shr ebp, 1 ; k=(i+j)/2
mov eax, dword[esp+ 96]
mul ebp
mov ecx, dword[esp+ 84]
cmp edx, 0
jne .e
add eax, dword[esp+ 88]
jc .e
mov dword[esp+ 0], eax
push ecx
push eax
call ebx
add esp, 8
cmp eax, 0
jle .3
dec ebp
mov ecx, dword[esp+ 0]
mov edi, ebp
mov dword[esp+ 4], ecx
jmp short .2
.3: jz .4
inc ebp
mov ecx, dword[esp+ 0]
mov esi, ebp
mov dword[esp+ 8], ecx
jmp short .2
.4: mov eax, dword[esp+ 0]
clc
.z: mov edx, dword[esp+ 4]
mov ecx, dword[esp+ 8]
lea esp, [esp+64]
pop ebp
pop edi
pop esi
pop ebx
ret 20
#i think consider the above not Nasm asm binsearch
#nobody among you can wrirte the same algo[check overflows in the count]
#in few space, in C
> so what does your program do? Is it a binary search written in (what
> you call) C?
hello?
#it is asm
> > 1, 2, 5, 7, 8, 8, 9, 13, 20
> > 1.000000, 2.000000, 5.000000, 7.000000, 8.000000, 8.000000, 9.000000,
> > 13.0000
>
> > For 0 w = 0- ww=0012FF50 find=1+
#here not find 0, not find a value <0, find 1 the min
#value in the list > of what search 0
> > For 1 r=0012FF50 find=1
#find in the list
> > For 2 r=0012FF54 find=2
>
> <snip more of same>
#it is the output of the test program
> and what does it mean? Have you shown your assembler is 1000 times
> faster than your C? Or 1000 times faster than my C?
>
> #it is 10 times safer than your C version
well since I havn't shown you any code I don't know how you can tell
this.
#i can say it for every C implementation
#without see them; yes i can make wrong on that
#but the routine would be more long and complex
How do you measure safety?
#in the bsearch() standard C library function....
#What safety can have one function that can do one error e.g
# a=*b where b is NULL
#and not has one error return code?
In what sense is your code 10 times
"safer" tahn typical C.
#for the above routine bsearch i can not say much
#because few run and few debug
#but for some other asm routine i can say: better what i write
#good if it is fast, good if it not fast
#possible because i consider it my creature?
#i praticate the defensive programming: to search errors at start of
#routines
#and search possible overflow of pointers, overflow index too
#and return error code [in eax and carry flag] if something is not right
#i have to say that overflow pointers or index would be cach better
#with seg fault from the OS
#but i don't know if some OS can not have the option of that
You claimed you could write asssmbler that was 10 to 1000 times faster
^^^^^
#i would say safer, faster is possible if all program is in asm
#i don't know, never had problem "to be fast" if not in
#break RSA-challenge numbers with not fast algo
#whitout any success...
than typical C. I think you were mistaken (I thought of a ruder word)
> #asm safer... people would laught on that
so you've dropped the faster claim?
> #a binsearch algo something as O(log(n)) can not be the bottle neck
> #right?-
could be if you had to search a lot of data
#just for copy it is O(n), so there someone
#has to make some effort in the optimization...
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-01-04 00:09 -0800 |
| Message-ID | <6217d738-8404-4dbf-9c7f-9249b8429c69@z17g2000vbe.googlegroups.com> |
| In reply to | #15378 |
On Jan 3, 5:26 pm, "io_x" <a...@b.c.invalid> wrote: > "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:f22ddb6f-9fe8-49db-ab29-2f85ea8f5efd@z12g2000yqm.googlegroups.com... > On Jan 2, 9:14 am, "io_x" <a...@b.c.invalid> wrote: > > "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel > > messaggionews:6be77116-b479- I'll give up soon. Your responses seem evasive and you frequently miss my point, either by accident or on purpose. > > > > #for example this: > > > > #i don't had the time full test it, > > > > #for example one has to try that for double , long double etc > > > > #you can write that in C or in assembly, your bsearch() can be faster > > > > #but my error detectrion is better of yours bsearch() > > > > i test it against double [64 bit double] too and for luck it send to stdout > > > the right output [afther some debug and some time to search the error > > > in the compare functions...] > > > as I've noted before I don't read code like this > > #define R return > #define P printf > #define F for > > > <snip horrid C> > > #only the test program is written in the C but WHAT DOES THE TEST PROGRAM DO? <snip assembler> > > so what does your program do? Is it a binary search written in (what > > you call) C? > > hello? > > #it is asm I'm talking about the C program you posted. > > > 1, 2, 5, 7, 8, 8, 9, 13, 20 > > > 1.000000, 2.000000, 5.000000, 7.000000, 8.000000, 8.000000, 9.000000, > > > 13.0000 > > > > For 0 w = 0- ww=0012FF50 find=1+ > > #here not find 0, not find a value <0, find 1 the min > #value in the list > of what search 0 > > > > For 1 r=0012FF50 find=1 > #find in the list > > > For 2 r=0012FF54 find=2 > > > <snip more of same> > > #it is the output of the test program > > and what does it mean? Have you shown your assembler is 1000 times > > faster than your C? Or 1000 times faster than my C? > > > #it is 10 times safer than your C version failure to repond noted. You won't explain what your C program does. You won't explain what "10 times safer" means and you won't offer any interpretation of your program's obscure output. And your C code is unreadable and posting style bizzare. <snip> bye.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-01-04 21:53 +1300 |
| Message-ID | <9miid0FpeqU10@mid.individual.net> |
| In reply to | #15399 |
On 01/ 4/12 09:09 PM, Nick Keighley wrote: > > And your C code is unreadable and posting style bizzare. I can't explain the former (I doubt anyone can), but the latter is due to his inability to use a broken Usenet client! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2012-01-04 16:14 +0100 |
| Message-ID | <4f046bf2$0$1392$4fafbaef@reader1.news.tin.it> |
| In reply to | #15399 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:6217d738-8404-4dbf-9c7f-9249b8429c69@z17g2000vbe.googlegroups.com...
On Jan 3, 5:26 pm, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel
> messaggionews:f22ddb6f-9fe8-49db-ab29-2f85ea8f5efd@z12g2000yqm.googlegroups.com...
> On Jan 2, 9:14 am, "io_x" <a...@b.c.invalid> wrote:
> > "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel
> > messaggionews:6be77116-b479-
I'll give up soon. Your responses seem evasive and you frequently miss
my point, either by accident or on purpose.
> > > > #for example this:
> > > > #i don't had the time full test it,
> > > > #for example one has to try that for double , long double etc
> > > > #you can write that in C or in assembly, your bsearch() can be faster
> > > > #but my error detectrion is better of yours bsearch()
>
> > > i test it against double [64 bit double] too and for luck it send to
> > > stdout
> > > the right output [afther some debug and some time to search the error
> > > in the compare functions...]
>
> > as I've noted before I don't read code like this
>
> #define R return
> #define P printf
> #define F for
>
> > <snip horrid C>
>
> #only the test program is written in the C
but WHAT DOES THE TEST PROGRAM DO?
#io_x
#the last C code test code i send...
#search the numbers 0..23 in the list {1, 2, 5, 7, 8, 8, 9, 13, 20};
#and print the result; the search routine use binary search is
#one .asm bserach routine
<snip assembler>
> > so what does your program do? Is it a binary search written in (what
> > you call) C?
>
> hello?
>
> #it is asm
I'm talking about the C program you posted.
#no
> > > 1, 2, 5, 7, 8, 8, 9, 13, 20
> > > 1.000000, 2.000000, 5.000000, 7.000000, 8.000000, 8.000000, 9.000000,
> > > 13.0000
>
> > > For 0 w = 0- ww=0012FF50 find=1+
>
> #here not find 0, not find a value <0, find 1 the min
> #value in the list > of what search 0
>
> > > For 1 r=0012FF50 find=1
> #find in the list
> > > For 2 r=0012FF54 find=2
>
> > <snip more of same>
>
> #it is the output of the test program
> > and what does it mean? Have you shown your assembler is 1000 times
> > faster than your C? Or 1000 times faster than my C?
>
> > #it is 10 times safer than your C version
failure to repond noted. You won't explain what your C program does.
You won't explain what "10 times safer" means and you won't offer any
interpretation of your program's obscure output.
And your C code is unreadable and posting style bizzare.
#bizzare...
<snip>
bye.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-01-01 12:28 -0800 |
| Message-ID | <dfd7ae19-4103-4f07-8e9b-c8a7e86f8fc6@q7g2000yqn.googlegroups.com> |
| In reply to | #15119 |
On Dec 28 2011, 4:06 pm, "io_x" <a...@b.c.invalid> wrote: > "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:916c68cc-1773-45b6-b400-7e39a69ce055@h3g2000yqa.googlegroups.com... > On Dec 22, 5:38 pm, "io_x" <a...@b.c.invalid> wrote: > > "Seebs" <usenet-nos...@seebs.net> ha scritto nel > > messaggionews:slrnjf6ocv.1rti.usenet-nospam@guild.seebs.net... > > > On 2011-12-22, 88888 Dihedral <dihedral88...@googlemail.com> wrote: <snip> > did you mean "would you consider it sensible to convert 5 to 10 lines > of C into assembly?". It would rather depend on the lines of C. How > fast does it need to be? Is it fast enough? Would recoding it in > assembler make any difference (likely not)? I think it very unlikely > that the vast majority of C code would benefit in anyway from this. > > It's just a way to waste time and degrades the quality of your code. > > > > Of course not. > > > > 1. It's a great way to introduce errors and bugs. > > > 2. It eliminates portability. > > > 3. It takes time. > > > 4. It is very unlikely to produce a measurable benefit. > > > i have just one argument against yours: > > all code going out from one assembly programmer is from 10 > > to 1000 times better the one not know assembly > > cite. Produce figures. You are mistaken. > > #i'm right > #for example this: > #i don't had the time full test it, > #for example one has to try that for double , long double etc > #you can write that in C or in assembly, your bsearch() can be faster > #but my error detectrion is better of yours bsearch() does it run 1000 times faster than a C version? What errors do you detect. I can't be bothered to read your assembler. I'll give you that you can actually write assembler. > ; would be like the C *library* bserach() function, with the only > ; difference return (u8*)-1 for error > ; return (u8*)-1 error, 0 not found, address of the found element in array > ; if return 0 [not found] > ; in ecx return the address element of the array < than key if exist > ; else ecx=0 > ; in edx return the address element of the array > than key if exist > ; else edx=0 > ;u8* __stdcall > ;binSearchR(u8* InPKey, u8* InBase, > ; u32 nElmBase, u32 SizeElmBase, i32 cmp(const u8* elm1, const u8* > elm2) ); <snip assembley code> > > this is only what i think > > so you just made that up? All assembler programs can run faster than > any Olympic athelete. I just think this is so, I have never seen an > assembler programmer run anywhere. I should have picked a better metephor. I was making the point that if you make things up you can make anything up. Assemler programs shit diamonds. this is only what i think. <snip. > > one can not be sure of all and has to syntesis his results > > please repost in a known language > > #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.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web