Fast Bit Operations Contest (unmoderated)
Skybuck Flying
The objective of this contest is to set and clear a bit at an arbitrary
memory address as fast as possible.
Implement one or multiple prototypes to take part in the contest:
// 8 bit versions
// 1 in 256 bits
procedure SetBit_8bit( BaseAddress : pointer; BitIndex : byte );
function GetBit_8bit( BaseAddress : pointer; BitIndex : byte ) : boolean;
procedure ClearBit_8bit( BaseAddress : pointer; BitIndex : byte );
procedure XorBit_8bit( BaseAddress : pointer; BitIndex : int64 );
// 16 bit versions
// 1 in 2^16 bits
procedure SetBit_16bit( BaseAddress : pointer; BitIndex : word );
function GetBit_16bit( BaseAddress : pointer; BitIndex : word ) : boolean;
procedure ClearBit_16bit( BaseAddress : pointer; BitIndex : word );
procedure XorBit_16bit( BaseAddress : pointer; BitIndex : word );
// 32 bit versions
// 1 in 2^32 bits
procedure SetBit_32bit( BaseAddress : pointer; BitIndex : longword );
function GetBit_32bit( BaseAddress : pointer; BitIndex : longword ) :
boolean;
procedure ClearBit_32bit( BaseAddress : pointer; BitIndex : longword );
procedure XorBit_32bit( BaseAddress : pointer; BitIndex : longword );
// 64 bit versions
// 1 in 2^32 * 8 bits
procedure SetBit_64bit( BaseAddress : pointer; BitIndex : int64 );
function GetBit_64bit( BaseAddress : pointer; BitIndex : int64 ) : boolean;
procedure ClearBit_64bit( BaseAddress : pointer; BitIndex : int64 );
procedure XorBit_64bit( BaseAddress : pointer; BitIndex : int64 );
All implementations will be bug tested, examined, and performance tested.
Code can be in Delphi or Assembler.
Code should work on 286 and above.
Processor specific code is to be mentioned and still interesting.
Processor detection code is also interesting.
Results will be posted along the way.
Multiple entries/versions are allowed.
Final results will be posted as well.
(I cross-posted a similiar thread to comp.lang.asm.x86 not realising that
it's a moderated newsgroup, my apologies to the newsgroup maintainer, but I
do not like moderated newsgroups, message approval takes too long and I do
not like censorship).
This (unmoderated) thread is cross-posted to alt.lang.asm instead.
(Prototypes renamed to original names as well ;))
Bye,
Skybuck.
//\\\\o//\\\\annabee <Free"
<sp...@hotmail.com>:
> Hello,
>
> The objective of this contest is to set and clear a bit at an arbitrary
> memory address as fast as possible.
:))) Hi Skybuck. Love your posts since long, even if I dont much frequent
those places you do. I remember smiling a lot at reading some of your
posts. Nothing unfriendly, btw.
> Bye,
> Skybuck.
Bye.
Herbert Kleebauer
>
> Hello,
>
> The objective of this contest is to set and clear a bit at an arbitrary
> memory address as fast as possible.
What's wrong with
BT—Bit Test
BTC—Bit Test and Complement
BTR—Bit Test and Reset
BTS—Bit Test and Set
Description
Selects the bit in a bit string (specified with the first operand, called the bit base) at the bitposition
designated by the bit offset operand (second operand), stores the value of the bit in the
CF flag, and sets the selected bit in the bit string to 1. The bit base operand can be a register or
a memory location; the bit offset operand can be a register or an immediate value:
• If the bit base operand specifies a register, the instruction takes the modulo 16, 32, or 64 of
the bit offset operand (modulo size depends on the mode and register size; 64-bit operands
are available only in 64-bit mode). This allows any bit position to be selected.
• If the bit base operand specifies a memory location, the operand represents the address of
the byte in memory that contains the bit base (bit 0 of the specified byte) of the bit string.
The range of the bit position that can be referenced by the offset operand depends on the
operand size.
See also: Bit(BitBase, BitOffset) on page 3-10.
Some assemblers support immediate bit offsets larger than 31 by using the immediate bit offset
field in combination with the displacement field of the memory operand. See “BT—Bit Test” in
this chapter for more information on this addressing mechanism.
This instruction can be used with a LOCK prefix to allow the instruction to be executed atomically.
In 64-bit mode, the instruction’s default operation size is 32 bits. Using an REX prefix in the
form of REX.R permits access to additional registers (R8-R15). Using an REX prefix in the
form of REX.W promotes operation to 64 bits. See the summary chart at the beginning of this
section for encoding data and limits.
• Bit(BitBase, BitOffset) — Returns the value of a bit within a bit string. The bit string is a
sequence of bits in memory or a register. Bits are numbered from low-order to high-order
within registers and within memory bytes. If the BitBase is a register, the BitOffset can be
in the range 0 to [15, 31, 63] depending on the mode and register size. See Figure 3-1: the
function Bit[RAX, 21] is illustrated.
Figure 3-1. Bit Offset for BIT[RAX, 21]
If BitBase is a memory address, the BitOffset can range has different ranges depending on
the operand size (see Table 3-2).
The addressed bit is numbered (Offset MOD 8) within the byte at address (BitBase +
(BitOffset DIV 8)) where DIV is signed division with rounding towards negative infinity
and MOD returns a positive number (see Figure 3-2).
Table 3-2. Range of Bit Positions Specified by Bit Offset Operands
Operand Size Immediate BitOffset Register BitOffset
16 0 to 15 -2^15 to 2^15 - 1
32 0 to 31 -2^31 to 2^31 - 1
64 0 to 63 -2^63 to 2^63 - 1
Skybuck Flying
"Herbert Kleebauer" <kl...@unibwm.de> wrote in message
news:459D40BF...@unibwm.de...
> Skybuck Flying wrote:
>>
>> Hello,
>>
>> The objective of this contest is to set and clear a bit at an arbitrary
>> memory address as fast as possible.
>
> What's wrong with
>
> BTC-Bit Test and Complement
> BTR-Bit Test and Reset
>
> BTS-Bit Test and Set
Where's the implementation ? ;)
Theory != Practice ;)
Bye,
Skybuck.
Stefan Meisner
>
> Theory != Practice ;)
Where's yours? ;-)
Regards
Stefan
Skybuck Flying
"Stefan Meisner" <stefan....@chello.at> wrote in message
news:5fed9$459d53f8$506d77ba$90...@news.chello.at...
>> Where's the implementation ? ;)
>>
>> Theory != Practice ;)
>
> Where's yours? ;-)
Mine has been ready for years.
Where's yours ? ;)
As I said on the other thread, I do not want to influence you guys.
However it's quite likely that we will see similiar implementations, after
all, it's only logic ;)
However I am also hoping that some have something extraordinary ;)
Bye,
Skybuck.
Frank Kotler
> Skybuck Flying wrote:
>
>>Hello,
>>
>>The objective of this contest is to set and clear a bit at an arbitrary
>>memory address as fast as possible.
>
>
> What's wrong with
>
> BT—Bit Test
> BTC—Bit Test and Complement
> BTR—Bit Test and Reset
From the part you snipped:
>> Code should work on 286 and above.
Absurd requirement, IMHO (even *I'm* past a 286!), but that's what he
said. You've participated in "Skybuck Flying"s "contests" before,
haven't you, Herbert? 'Nuff said.
Best,
Frank
Skybuck Flying
"Frank Kotler" <fbko...@verizon.net> wrote in message
news:I4dnh.4896$Lh.1284@trndny09...
> Herbert Kleebauer wrote:
>> Skybuck Flying wrote:
>>
>>>Hello,
>>>
>>>The objective of this contest is to set and clear a bit at an arbitrary
>>>memory address as fast as possible.
>>
>>
>> What's wrong with
>>
>> BTC唯it Test and Complement
>> BTR唯it Test and Reset
>
> From the part you snipped:
>
> >> Code should work on 286 and above.
>
> Absurd requirement, IMHO (even *I'm* past a 286!), but that's what he
> said.
Why would that be absurd ?
Does the 80486 have any additional instructions that the 286 does not have
which might be usefull for the task at hand ?
Otherwise your nagging complaint is absurd !!!!
> You've participated in "Skybuck Flying"s "contests" before, haven't you,
> Herbert? 'Nuff said.
Hmm interesting.
It's Herbert the same dude that had the fastest implementation but was
disqualified for cheating LOL.
Cheating is allowed as well. It's always interesting to see the cheats.
However cheats will be disqualified =D
Bye,
Skybuck.
Skybuck Flying
I will allow a new phenomenon in this contest:
It is allowed to add your implementation to this thread *encrypted* in AES.
This is to prevent other people from deriving their implementations based on
yours.
Thus your entry is protected from infringment.
The contest will only last for a few days maybe a few weeks max.
After I feel confident about my implementations/entries and after everybody
else feels confident about their implementations/entries and once we agree
to end "phase 1, the entry phase" then all contributions will be decrypted
and the examination, bug test, and performance test can begin. (We will all
reveal our passwords and no further entries are allowed for phase 1)
Cheats will be disqualified =D
And a phase 1 winner will be announced =D
Then phase 2 starts... in phase 2 it is allowed to derive new
implementations based on the implementations of others to try and improve on
each other's work.
A new encrypted phase could begin if so desired... and the process repeats
until no further improvement is achieved.
Thus multiple winners would be possible.
Bye,
Skybuck ;)
Good idea or no ? :)
Jim P
skybuck as normal you do not stop and think
There is a processor instruction that does a bit test, bit set etc.
what can be faster than using that instruction - - -
and why bother showing code that implements a single processor instruction
it would be simply inlined - - -
so this is a contest to see how many people know about the processor
instruction and how to inline it in delphi - - - correct.
Jim P.
Dunny
Jim P <Ji...@mad.scientist.com> typed:
> so this is a contest to see how many people know about the processor
> instruction and how to inline it in delphi - - - correct.
It's a contest to speed up Skybuck's delphi code for him. The fact that he
even wants functions/procedures to do these operations is quite telling, at
least in /this/ newsgroup.
D.
Jim P
Please note that Skybuck will always push something to the limit and
justify the reasons for it.
such as in this case even after being told that it is a single processor
instruction --he has to find ways of justifing and continuing. - - -
that is skybuck.
this is a simply one line of assembly code to run the processor
instruction that he wants to do and have us find a delphi sequence to
perform the same task. - - -
Refuses to realize that the overhead of a function routine is a lot more
than the single processor instruction - - - - and still wants to make
this a contest and then complains when it is pointed out that is is one
processor instruction that the poster did not show how it is implemented
and then went right on trying to make this a bigger and more defined
contest
You will also notice that skybuck really does not do any real
programming - - - more just plays around and tries to get attention
that is him - - -
Jim P.
Herbert Kleebauer
> Herbert Kleebauer wrote:
> said. You've participated in "Skybuck Flying"s "contests" before,
> haven't you, Herbert? 'Nuff said.
Had to ask Google, but now I remember the thread "Reversing bit
order in delphi" (and one about packet driver). Will leave this
thread as fast as I did the other one.
robert...@yahoo.com
Skybuck Flying wrote:
> > Absurd requirement, IMHO (even *I'm* past a 286!), but that's what he
> > said.
>
> Why would that be absurd ?
>
> Does the 80486 have any additional instructions that the 286 does not have
> which might be usefull for the task at hand ?
>
> Otherwise your nagging complaint is absurd !!!!
You do realize that the 286 is a sixteen bit processor and can't run
any version of Windows since 3.11 (or even Win 3.x in 386Enh mode), nor
will any semi-recent version of Delphi run on a 286? Even NT4 required
a 486.
And even if you did write 16 bit code for this, it would *not* work
with current 32 bit applications.
As compared to the 386, the 486 does have the bit test/set
instructions, which may very well be useful for the task at hand.
rh...@cs.ucr.edu
Jim P wrote:
>
> You will also notice that skybuck really does not do any real
> programming - - - more just plays around and tries to get attention
>
> that is him - - -
What is also amusing is how Wannabee added the one positive remark in
this thread. Birds of a feather, you know?
Of course, when someone complains about accidentally posting to a
moderated newsgroup you immediately suspect their real intentions.
Cheers,
Randy Hyde
Jim P
Jim P.
//\\\\o//\\\\annabee <Free"
<sp...@hotmail.com>:
> Thus multiple winners would be possible.
;) How about allowing multithread processing for the solution?
Does it have to be portable ???
>
> Bye,
> Skybuck ;)
>
> Good idea or no ? :)
Genious. You making some kind of library right? The fastest or/and/xor
library? Expect a post from Randall Hyde, later on, with a plug to his
infamous
< http://hlahlahla/hla/hla/StandardXORLibrary >
:)))
Cheeers.
Skybuck Flying
<robert...@yahoo.com> wrote in message
news:1167958580.6...@v33g2000cwv.googlegroups.com...
>
> Skybuck Flying wrote:
>> > Absurd requirement, IMHO (even *I'm* past a 286!), but that's what he
>> > said.
>>
>> Why would that be absurd ?
>>
>> Does the 80486 have any additional instructions that the 286 does not
>> have
>> which might be usefull for the task at hand ?
>>
>> Otherwise your nagging complaint is absurd !!!!
>
>
> You do realize that the 286 is a sixteen bit processor and can't run
> any version of Windows since 3.11 (or even Win 3.x in 386Enh mode), nor
> will any semi-recent version of Delphi run on a 286? Even NT4 required
> a 486.
I was in a computer shop once and heard somebody say that windows ran on a
286.
The owner of the store did not believe him, but I did ;)
Maybe the dude ment windows 3.1.
Anyway if windows 95 really does not run on a 286, then the 286 can be
scrapped.
So new rule: 386 and above.
> And even if you did write 16 bit code for this, it would *not* work
> with current 32 bit applications.
>
> As compared to the 386, the 486 does have the bit test/set
> instructions, which may very well be useful for the task at hand.
Good to know this in case I ever want to write 16 bit programs for dos for a
286 ;)
Bye,
Skybuck.
Skybuck Flying
>
> what can be faster than using that instruction - - -
> and why bother showing code that implements a single processor instruction
If you believe that would be the fastest implementation then why don't you
enter the contest with it ? hmmmm ? ;)
Bye,
Skybuck.
Skybuck Flying
"Jim P" <Ji...@mad.scientist.com> wrote in message
news:OpSdnYySmaTOLgDY...@comcast.com...
That just shows Jim P. doesn't really read my postings not does he
understands them :)
Bye,
Skybuck.
Skybuck Flying
Ah your lack of skill is showing (again) ! ;)
Is this really your true nature, a cheater which can't really code and use
instructions ? :)
Bye,
Skybuck.
Frank Kotler
Heh! You must be posting from a.c.l.b-d. Which might mean you don't know
Wannabee (he spells his name different ways to avoid killfiles). You
may find out...
And the moderated ng that Skybuck Flying mentioned accidentally posted
to is news:comp.lang.asm.x86 - which *is* moderated. I don't think the
alt heirarchy *can* be moderated...
Best,
Frank
Betov
news:1167960834.3...@42g2000cwt.googlegroups.com:
> Of course, when someone complains about accidentally posting to a
> moderated newsgroup you immediately suspect their real intentions.
And don't forget the famous reverse case, clown, when
you did your best to convince the ALA participants to
go CLAX, instead, because it was impossible for you,
at ALA, to shut me up, and to win any debate against
me. (What you also loosed).
:)
Betov.
Betov
@news1.zwoll1.ov.home.nl:
> Bye,
> Skybuck.
Outchhh...
:)
Betov.
Jim P
Jim P.
Skybuck Flying
Yeah classic behaviour for people who can't win a contest.
I am sure you know everything about that Jim P. ;)
Bye,
Skybuck.
Bodhi
>>Ah skybuck -- he just insulted you
> Yeah classic behaviour for people who can't win a contest.
>
> I am sure you know everything about that Jim P. ;)
>
I find it rather unusual, as well as amusing, that you would describe
someone that insults others as one that "can't win a contest". And, in
the very next line, it becomes apparent that the intention behind your
entire post is to be an insult !!
And in other posts from this same thread, you wrote:
...your nagging complaint is absurd !!!!
...the same dude that had the fastest implementation but was
disqualified for cheating...
...doesn't really read my postings not does he understands them...
Ah your lack of skill is showing (again) !
and finally:
Is this really your true nature, a cheater which can't really code
and use instructions ?
Very odd, to say the least.
Robert Redelmeier
The instruction speed (and optimum) will mostly depend on the type
of memory being hammered. In L1, L2, RAM or bletcherous VM & vidram?
-- Robert
Skybuck Flying
"Bodhi" <bo...@dharma.net> wrote in message
news:1-SdnTgS6sxX-APY...@giganews.com...
I have 7 implementations already.
So far this thread has been full with insults only.
Where are the implementations ?
Are you not able to perform and produce ?
Sure seems like it =D
Bye,
Skybuck ;)
Bodhi
And now you are trying to change the subject, and get the focus of
attention off of yourself. That is a typical behavioral pattern of
someone who knows they are "caught holding the bag", so to speak.
I should tell you that I was expecting you to respond with pretty much
what you wrote.
I can sense in reading your posts that you are very pablum, probably
anal, and extremely predictable. More than likely, I can tell you what
you are thinking even now, while reading this.
In summary, you're not at all original.
rh...@cs.ucr.edu
Jim P wrote:
> >
> > Of course, when someone complains about accidentally posting to a
> > moderated newsgroup you immediately suspect their real intentions.
> > Cheers,
> > Randy Hyde
> >
> you must be new to this group and oh it is not a moderated newsgroup.
>
> Jim P.
Look back at the original post and notice how he posted it to
comp.lang.asm.x86, which is moderated. You might notice that there are
multiple newsgroups been cross-posted to here. For example, I am
responding to your post in alt.lang.asm.
Cheers,
Randy Hyde
rh...@cs.ucr.edu
I'd comment, Rene, that you're getting senile. The truth, however, is
that you've been senile for quite some time. Let me refresh your memory
-- Hutch was the one who pushed the big switch to CLAX. Though I
certainly support the idea and believe that people who *really* want to
ask x86 questions and get serious answers without all the crap you
spread around here ought to post to CLAX rather than ALA, I'm hardly
pushing everyone to leave ALA so they can avoid you. If they want to
avoid you (and wannabee), all they've got to do is add Betov to their
kill list and ignore all messages that have "///" in the subject line.
It was worked like a charm for people. I realize it hurts you to be
ignored by people around here, but the truth is you brought it on
yourself.
Cheers,
Randy Hyde
Betov
news:1168019021....@s34g2000cwa.googlegroups.com:
No, clown, i am not talking about your last "///" trick for
helping yourself at breaking the threads as much as possible.
I am talking of something older than that, and if you don't
recall of it, i am quite sure that several readers recall of
it perfectly.
Betov.
rh...@cs.ucr.edu
Betov wrote:
>
> No, clown, i am not talking about your last "///" trick for
> helping yourself at breaking the threads as much as possible.
> I am talking of something older than that, and if you don't
> recall of it, i am quite sure that several readers recall of
> it perfectly.
Senile?
Provide the links, please.
Cheers,
Randy Hyde
J French
wrote:
>
><robert...@yahoo.com> wrote in message
>news:1167958580.6...@v33g2000cwv.googlegroups.com...
>>
>> Skybuck Flying wrote:
>>> > Absurd requirement, IMHO (even *I'm* past a 286!), but that's what he
>>> > said.
>>>
>>> Why would that be absurd ?
>>>
>>> Does the 80486 have any additional instructions that the 286 does not
>>> have
>>> which might be usefull for the task at hand ?
>>>
>>> Otherwise your nagging complaint is absurd !!!!
>>
>>
>> You do realize that the 286 is a sixteen bit processor and can't run
>> any version of Windows since 3.11 (or even Win 3.x in 386Enh mode), nor
>> will any semi-recent version of Delphi run on a 286? Even NT4 required
>> a 486.
>
>I was in a computer shop once and heard somebody say that windows ran on a
>286.
>The owner of the store did not believe him, but I did ;)
You were rright
>Maybe the dude ment windows 3.1.
1 comes before 2, and 2 comes before 3
>Anyway if windows 95 really does not run on a 286, then the 286 can be
>scrapped.
95 requires the 386 - and actually few people missed .286 code
- it was horrible
>So new rule: 386 and above.
Nope - that is an old rule ! :-}
>> And even if you did write 16 bit code for this, it would *not* work
>> with current 32 bit applications.
16 bit stuff works in both 9x and NT+
- backwards compatibility
>> As compared to the 386, the 486 does have the bit test/set
>> instructions, which may very well be useful for the task at hand.
I don't think the 486 brought in much in the way of instructions,
mostly it introduced an element of RISC and pre-fetch
>Good to know this in case I ever want to write 16 bit programs for dos for a
>286 ;)
It is very possible that you will write code for an 8086, let alone
that gross mistake the .286
You might get into embedded software, and old, well known instruction
sets are .. well .. easier to get right.
It would be a good idea to look into those areas, also to find out why
the normally talented Intel engineers produced such a dog pile.
Rudy Velthuis
> > Maybe the dude ment windows 3.1.
>
> 1 comes before 2, and 2 comes before 3
Indeed. My first encounter with Windows was version 1 on a 286. Then, I
thought more of Gem for DOS, since it had a nicer API. <g>
--
Rudy Velthuis http://rvelthuis.de
"I hear Glenn Hoddle has found God. That must have been one hell
of a pass." -- Bob Davies.
Jim P
fastest?
that is for a beginner -- - a class project for begining computer class.
Not worth my time or effort.
nor others -- ever wonder why only one has posted what you call an entry
Jim P.
Jim P
I second that
Jim P.
Jim P
I agree
when you see skybuck over time you will see a very clear pattern --
wants attention -- needs attention -- will fight and push anything to
the limit and if people comment - - gets very nasty very fast. - - -
and look at the number of post that he has started on this 1 line
assembly contest - -- - - Just to get attention and to make himself look
big on this newsgroup and maybe like he knows something
One of the very first reply's pointed out the processor instruction that
would do this in instruction - - - the fastest possible way -- but he
did not put that into an implementation so it did not count - - -
He did not implement it into some code - - - like why that is first week
of the first computer class on how to do - - -
and yet Skybuck - - - keeps pushing and trying to get responses and when
people go - - ah what about this or you could check here --- he calls
that cheating - - - -
Jim P.
Bodhi
I concur with everything you've said, as well.
But watching as Flysuck get all flustered and discomposed is the amusing
part, for me, that I mentioned in my first post.
What I don't quite understand is why he would post here and at
alt.comp.lang.borland-delphi with the same question. That's a bit
confusing to me. Unless,...it's like you said: All he's really
interested in is the attention.
J French
<newsg...@rvelthuis.de> wrote:
<snip>
>"I hear Glenn Hoddle has found God. That must have been one hell
> of a pass." -- Bob Davies.
How curious, in about 1982 I met Glenn Hoddle in a pub in Broxbourne
- he was hogging bar space and drinking orange juice
My memory is that he was a boring turd
- I must confess that I was rather dismissive
Rudy Velthuis
> What I don't quite understand is why he would post here and at
> alt.comp.lang.borland-delphi with the same question.
Because Delphi has a built-in assembler, so any assembler solutions
should probably work in Delphi too.
The fact that he is looking for something as simple as setting or
resetting a bit means he apparently has no clue at all, and probably
produced something that was so convoluted and darned slow that he
decided to let others do it for him. <g>
--
Rudy Velthuis http://rvelthuis.de
"You ask me if I keep a notebook to record my great ideas. I've
only ever had one." -- Albert Einstein.
Rudy Velthuis
> what contest?
And what can we win? More insults from Sky?uck Farting? <g>
--
Rudy Velthuis http://rvelthuis.de
"I think 'Hail to the Chief' has a nice ring to it."
-- John F. Kennedy (1917-1963) when asked what is his favorite
song
Bodhi
> Bodhi wrote:
>
>> What I don't quite understand is why he would post here and at
>> alt.comp.lang.borland-delphi with the same question.
>
> Because Delphi has a built-in assembler, so any assembler solutions
> should probably work in Delphi too.
>
> The fact that he is looking for something as simple as setting or
> resetting a bit means he apparently has no clue at all, and probably
> produced something that was so convoluted and darned slow that he
> decided to let others do it for him. <g>
>
Thanks for clearing that up Rudy.
J French
wrote:
The thing is that while 'Skybuck' is an immature little turd, who is
extremely annoying and an utter pest
- the tit head has half what it takes to be a decent programmer
sheer bloody minded persistence
Irritating little sod - but possibly not a waste of space
J French
Also, if Skynuisance wants to prove that he is half competent, then he
can prove it by debugging SNAP.ASM which is the ultimate TSR by Ray
Duncan in the MSDOS Encyclopedia
There are two faults, one is obvious, and the other is comical as it
it negates the whole design of the demonstration.
My view is that both 'errors' were deliberate to filter out morons.
I used to be the TSR programmer from hell, but can't be arsed to do
the same for NT+
Dunny
Rudy Velthuis <newsg...@rvelthuis.de> typed:
> Bodhi wrote:
>
>> What I don't quite understand is why he would post here and at
>> alt.comp.lang.borland-delphi with the same question.
>
> Because Delphi has a built-in assembler, so any assembler solutions
> should probably work in Delphi too.
>
> The fact that he is looking for something as simple as setting or
> resetting a bit means he apparently has no clue at all, and probably
> produced something that was so convoluted and darned slow that he
> decided to let others do it for him. <g>
What gets me most is that he wants a delphi function wrapper around this. We
all know that the overheads of a CALL are quite high if you're going to be
using this en-masse, and as there's bitwise operators in Delphi to do this
(well documented in the helpfile), I have to wonder when he'll get a clue
here.
Okay, although the bitwise operators will not be quite as fast as dedicated
x86 instructions for setting/resetting bits, won't they be more than fast
enough for anything he wants to do?
I'm no assembly "expert" like others around here, but wrapping a single x86
instruction around a CALL/RET pairing seems a bit daft, imo.
D.
Rudy Velthuis
> > The fact that he is looking for something as simple as setting or
> > resetting a bit means he apparently has no clue at all, and probably
> > produced something that was so convoluted and darned slow that he
> > decided to let others do it for him. <g>
>
> What gets me most is that he wants a delphi function wrapper around
> this.
Like I said, he is rather clueless. He wants something he can simply
use, in Delphi, not something he should understand. He has been posting
to alt.comp.lang.borland-delphi a little longer, and has shown he is
rather clueless.
He posted rather obfuscated and weird code where he hoped to show what
a great thinker he was, but it was in fact crap full of errors which
showed he did not understand one bit of what he was actually doing.
When told his code was dangerous (e.g. using dangling pointers, etc.),
he required proof, or insulted people of incompetence when nothing
happened in his code, etc., not knowing that no visible error is not
really proof of good code. When told to first read a few books about
programming and the language, he isn ot interested.
That is how he is. I guess he is terribly young, or unskilled in social
life. I have put him in my killfile. He is a waste of time. One could
call him a help vampire.
--
Rudy Velthuis http://rvelthuis.de
"Politicians are like diapers. They should be changed often, and
for the same reason." -- Anonymous
Frank Kotler
...
> Not worth my time or effort.
Thanks for posting to let us know you won't be posting, Jim! :)
> nor others -- ever wonder why only one has posted what you call an entry
If I may drag the discussion off-topic - away from Skybuck's
psychological problems (if any)... Forget "entry" (Skybuck's notion of
"contest" seems misguided to me - how about "cooperating to solve a
problem"?) - how come only one has posted an "answer"? In c.l.a.x - that
nasty censored newsgroup - Tim Roberts posted:
------------------
The right way to do this in Delphi is to define BaseAddress as a "set of
byte". Then, TurnBitOn becomes
BaseAddress := BaseAddress + BitIndex;
and TurnBitOff becomes
BaseAddress := BaseAddress - BitIndex;
IsBitSet becomes
IsBitSet := BitIndex in BaseAddress;
---------------------------------------
Weird... I would have expected "Set of Bit" to be what delphi wanted to
hear... but I don't know delphi... The question would be: what code does
delphi produce from this, and can/should it be optimized?
Herbert posted the relevant instructions, but didn't show how to
integrate 'em into delphi - I haven't got the slightest idea. I would
have expected Wannabee to fill that in, being an assembly language
programmer with some experience in delphi... Or try to persuade Skybuck
that delphi sucks and he should be using RosAsm. http://rosasm.org
Then... is that really the best way to do it? I assume it is, but it's
not unheard of for discrete instructions to be faster than a single
"complex" instruction. And there may be instructions available only in
newer processors that would be even faster.
It isn't exactly a mysterious operation. "Planed" mode graphics used to
do a lot of it... "Fast" ways of doing it, even with 8086 instructions,
are known. (if there's any point in discussing that)
Whether Skybuck's motivation is "information", or something else, there
may be others lurking in one ng or the other who would like to know!
We're blowing an opportunity to learn from each other!
Best,
Frank
Jim P
> are known. (if there's any point in discussing that)
>
> Whether Skybuck's motivation is "information", or something else, there
> may be others lurking in one ng or the other who would like to know!
> We're blowing an opportunity to learn from each other!
>
> Best,
> Frank
Frank
if you noticed he is doing this in two newsgroups at the same time
and also has started how many post about this is it 3 or 4 or has it
reached 5 - - just to get more activity and attention going - - that is
what he is after - - - attention - - - of any type.
Jim P.
Frank Kotler
> Frank Kotler wrote:
>
>> are known. (if there's any point in discussing that)
>>
>> Whether Skybuck's motivation is "information", or something else,
>> there may be others lurking in one ng or the other who would like to
>> know! We're blowing an opportunity to learn from each other!
>>
>> Best,
>> Frank
>
>
>
> Frank
>
> if you noticed he is doing this in two newsgroups at the same time
Three, if you count c.l.a.x :)
> and also has started how many post about this is it 3 or 4 or has it
> reached 5 - - just to get more activity and attention going - - that is
> what he is after - - - attention - - - of any type.
Okay. What's your motivation for giving it to him? :)
I don't care much what Skybuck's motivation is. He raises some
interesting questions, as well as some really weird ideas (IMO - and I
*like* weird ideas!) I don't have experience with the instructions in
question, but I'm pretty sure sure I can figure it out. But I'm
*totally* clueless how to do it in Delphi. If someone can show him how
to "inline" these instructions in Delphi, it'll put an end to his
"attention-getting", no?
I don't think Delphi is "my thing", but I'm slightly curious what can -
and can't - be done in it. I've been chastised for being too willing to
help "those unwilling to help themselves", but I've found it's simpler
(and makes a shorter thread) to post the answer than to discuss it...
Best,
Frank
//\\\\o//\\\\annabee <Free"
<fbko...@verizon.net>:
When Delphi went .net it was dead to me. Anyways, it would not be very
difficult to view the code produced in the CPU window of the debugger.
With source code intertwined and all. Just like in RosAsm - only more
awkward with Delphi. But Delphi is not installed here. Each time I
reinstall windows, Delphi dies. And I dont think its worth it anymore for
me to reinstall it. My RosAsm codebase is now more powerful than my Delphi
codebase ever was. And RosAsm doesnt need a full reinstall each time I
reinstall windows, and RosAsm starts in instant time, while Delphi takes 7
seconds just to load. Further more the sourcenavigation features of Delphi
are so much more crippeled than RosAsm one, so even to look at my old
sourcecode, I now prefer to use Notepad. Actually I use a texteditor I
wrote myself in RosAsm for this now.
> Then... is that really the best way to do it?
No. The Delphi set feature is imo broken.
It is more work to use it than using theese features in assembly directly.
Plus there is no way to overwrite the whole flag (set variable), without a
typecast if I recall well. (When you need to store/load it to a file for
instance). Its been 3 years since I used Delphi, and most of it is fading
fast away.
Frank Kotler
Okay. So Starbuck's right, I guess. This really *is* a difficult
question! I wouldn't have thought so. Shows how much I know...
Best,
Frank
rh...@cs.ucr.edu
Frank Kotler wrote:
>
> I don't think Delphi is "my thing", but I'm slightly curious what can -
> and can't - be done in it. I've been chastised for being too willing to
> help "those unwilling to help themselves", but I've found it's simpler
> (and makes a shorter thread) to post the answer than to discuss it...
Dephi has a built-in assembler, BASM (quite similar to TASM), that
would allow you to inject a BT or BTS instruction in-line. As Delphi is
x86 only, you don't have to worry about portability issues.
Cheers,
Randy Hyde
Skybuck Flying
I urge you to make an implementation otherwise you will also look like fools
just like Jim P. at the end of this contest.
Bye,
Skybuck.
Dunny
Skybuck Flying <sp...@hotmail.com> typed:
> Jim P. is a troll and always looks like a fool.
>
> I urge you to make an implementation otherwise you will also look
> like fools just like Jim P. at the end of this contest.
It seems to me that writing your application for you would make anyone look
like a fool.
D.
Bodhi
Allow me to inform you of this fact, there is no contest.
And, while I'm at it, you're the only one that looks like a fool.
Skybuck Flying
"Dunny" <paul....@ntlworld.com> wrote in message
news:MCTnh.14573$Wy6....@newsfe1-win.ntli.net...
Oh look it's Dunny the fool.
Dunny the fool whole believes a single BTS instruction is faster than
multiple different instructions.
You should have done a Google on BTS instructions Dunny the fool.
If you had Googled for BTS instruction you would learned that it is well
known among assembler programmers that BTS is slow.
Many books about assembler mention BTS is slow as well.
However newer processor might implement BTS is fast.
Currently however the X2 3800+ executes BTS slower than my current bitset
implementation.
Bye,
Skybuck.
Skybuck Flying
"Rudy Velthuis" <newsg...@rvelthuis.de> wrote in message
news:xn0f0v2zp...@news.online.de...
> Jim P wrote:
>
>> what contest?
>
> And what can we win? More insults from Sky?uck Farting? <g>
You won the title "fool".
For assuming BTS is faster.
Bye,
Skybuck.
Jim P
Hum that is an interesting comment - - - - am I really
Look at all of the other peoples responses to you - - - -
that answers it properly
and Skybuck - - you do not even know when you are looking like the fool
Just like in Sept - - when you keep pushing that crazy Idea of yours. - -
Don't care about the facts - - just have to prove that your idea is
right - - - even if it is crazy and don't understand the effects of it.
wanting to collect and send to millions of people 1 gig files each month
free - - - - and install programs on peoples computers to help with
this and tie up their upload bandwidth --- and not let the people that
you installed this program on know about it ----
Then you got ticked off at your ISP for doing something they did not
like and you refused to understand what - or did not want to understand
it. - - and wanted to get even with them - - - - - someway - - somehow
and I am the toll and the fool - - - -
and what makes me look like a fool - - If I decide this contest is not
worth my time to show someone how to inline a 1 line assembly statement
that is clearly shown how in the manual -- - and put this into a
function or procedure call that will take a lot more machine code and a
lot more processor time than the one line assembly statement takes. - -
- so much so that it will be hard to detect and measure the time the one
line assembly statement takes and you refuse to stop and realize this - - -
and from prior post you were doing testing of inline functions, so you
know how to inline code. - - - -
Jim P.
Skybuck Flying
It's insulting to have to deal with fools like Jim P. who claims BTS is a
fast instruction.
It's well known by anybody in the field that it is SLOW.
Bye,
Skybuck.
Skybuck Flying
"J French" <ere...@nowhere.uk> wrote in message
news:459ea0d...@news.btopenworld.com...
> On Fri, 5 Jan 2007 08:03:23 +0100, "Skybuck Flying" <sp...@hotmail.com>
> wrote:
>
>>
>><robert...@yahoo.com> wrote in message
>>news:1167958580.6...@v33g2000cwv.googlegroups.com...
>>>
>>> Skybuck Flying wrote:
>>>> > Absurd requirement, IMHO (even *I'm* past a 286!), but that's what he
>>>> > said.
>>>>
>>>> Why would that be absurd ?
>>>>
>>>> Does the 80486 have any additional instructions that the 286 does not
>>>> have
>>>> which might be usefull for the task at hand ?
>>>>
>>>> Otherwise your nagging complaint is absurd !!!!
>>>
>>>
>>> You do realize that the 286 is a sixteen bit processor and can't run
>>> any version of Windows since 3.11 (or even Win 3.x in 386Enh mode), nor
>>> will any semi-recent version of Delphi run on a 286? Even NT4 required
>>> a 486.
>>
>>I was in a computer shop once and heard somebody say that windows ran on a
>>286.
>
>>The owner of the store did not believe him, but I did ;)
>
> You were rright
>
>>Maybe the dude ment windows 3.1.
>
> 1 comes before 2, and 2 comes before 3
>
>>Anyway if windows 95 really does not run on a 286, then the 286 can be
>>scrapped.
>
> 95 requires the 386 - and actually few people missed .286 code
> - it was horrible
>
>>So new rule: 386 and above.
>
> Nope - that is an old rule ! :-}
>
>>> And even if you did write 16 bit code for this, it would *not* work
>>> with current 32 bit applications.
>
> 16 bit stuff works in both 9x and NT+
> - backwards compatibility
Good point French.
I shall stick with the 286 rule.
Since the BTS instruction is crap anyway.
Bye,
Skybuck.
Jim P
one with some of the best answers - - -
and give him the title of fool -- - which I figured that I won - - -
and from you - - - we should be proud to be called a fool as this
reflects directly back at you. - - -
you never give up a point and just argue it to death - - - even when
proven wrong again and again and again - - and if someone points out
that you might not be right - - you reduce yourself to insults and
attacks upon them - - - just as you have done to most of the people that
have responded to you. -- and the one with the best answer you now have
attacked him for not doing a full formal implementation - - this is not
a beginner Programming class. - - people here are expected to have some
basic working knowledge of programming - - Know how to read a manual - -
- and not have everything spoon feed to them - - -
Jim P.
Skybuck Flying
prototype:
procedure SetFourBits_8bit(
BaseAddress1 : pointer; BitIndex1 : byte;
BaseAddress2 : pointer; BitIndex2 : byte;
BaseAddress3 : pointer; BitIndex3 : byte;
BaseAddress4 : pointer; BitIndex4 : byte );
etc...
Bye,
Skybuck.
Dunny
Skybuck Flying <sp...@hotmail.com> typed:
> "Dunny" <paul....@ntlworld.com> wrote in message
> news:MCTnh.14573$Wy6....@newsfe1-win.ntli.net...
>> In news:enovug$lv6$1...@news5.zwoll1.ov.home.nl,
>> Skybuck Flying <sp...@hotmail.com> typed:
>>
>>> Jim P. is a troll and always looks like a fool.
>>>
>>> I urge you to make an implementation otherwise you will also look
>>> like fools just like Jim P. at the end of this contest.
>>
>> It seems to me that writing your application for you would make
>> anyone look like a fool.
>
> Oh look it's Dunny the fool.
>
> Dunny the fool whole believes a single BTS instruction is faster than
> multiple different instructions.
And where did I say that BTS was faster? Come on, a google-groups url will
do as proof.
I might even have mentioned that I use bitwise operators (xor, or, and) in
my own code. Can't say I've ever used BTS! In fact, what I actually said was
that the delphi bitwise operators might be slower than their
single-instruction asm equivalents. Knowing how Delphi's compiler works,
it's quite probable.
I think that you're getting pissed because your ruse to get others to write
code for you has been rumbled...
D.
Jim P
> "Dunny" <paul....@ntlworld.com> wrote in message
> news:MCTnh.14573$Wy6....@newsfe1-win.ntli.net...
>
>>In news:enovug$lv6$1...@news5.zwoll1.ov.home.nl,
>>Skybuck Flying <sp...@hotmail.com> typed:
>>
>>
>>>Jim P. is a troll and always looks like a fool.
>>>
>>>I urge you to make an implementation otherwise you will also look
>>>like fools just like Jim P. at the end of this contest.
>>
>>It seems to me that writing your application for you would make anyone
>>look like a fool.
>
>
> Oh look it's Dunny the fool.
>
> Dunny the fool whole believes a single BTS instruction is faster than
> multiple different instructions.
Wow - - skybuck actually believes that multiple instructions can be
faster than this one instruction - - wow - - - -
>
> You should have done a Google on BTS instructions Dunny the fool.
>
> If you had Googled for BTS instruction you would learned that it is well
> known among assembler programmers that BTS is slow.
>
So I googled BTS - - - 'Intel Pentium BTS instruction' ---
did not find what skybuck says that he found - - -
what I found is some timing information - - the BTS instruction takes
between 7 and 13 clocks depending upon location and indexing (Register
or memory or indexed)
Note the AND and OR and XOR instructions are faster if you have a bit
pattern - -- the BTS, BTR, BT use a bit offset (position) that must be
converted into bit position - - - if you do not have a pattern then the
creation or getting of the pattern takes additional processor
instructions and clock cycles.
a move instruction depending upon the locations (Register to Register or
Memory location indexed to Memory location indexed ) varied from 3
clocks to 22 clocks.
so Skybuck - - I have a contest for you - - - to find an assembler level
coding that is faster than BTS or BTR or BT to test or set or clear a
bit in a memory location - - - -
> Many books about assembler mention BTS is slow as well.
>
OH yea - - - where - - show references - - -
> However newer processor might implement BTS is fast.
>
I would not even consider any processors that are not 1 gig or faster -
- 90% of computers are in that area now days. - - -
and the next statement says that on a new processor the BTS is slower. -
- - Prove it.
> Currently however the X2 3800+ executes BTS slower than my current bitset
> implementation.
Please show me the proof --- you say so much BS that it is hard to take
anything that you say at face value
so the code and the timing results - - computer and memory access types
- - - make it a fair test - - - - -
It is hard to believe that a single instruction is slower than a couple
of instructions --- simply the time for the instruction fetch and decode
is most of the clock cycles - - - - - and by the time you do 2 or 3
simple instructions - simply the cycles required for instruction fetch
and decode is going to be more than the total clock cycles for 2 or 3
instructions - - - Assuming that the location is not in a register - -
as you are interested in this being for huge chucks of memory - - -
So Skybuck - - your fighting to prove something and saying anything to
prove your point gets blasted out of the water so to speak or shown for
what it is - - - just arguing to argue - - - which is what you do most
of the time and now one of your buzz words is to call someone a fool
that does not agree with you - - - - - - - while you are the one that is
wrong and refuses to stop and take a second to see what you are saying -
- - and how you are coming off to others. - - - -
Jim P. A programmer that takes pride in being calld a fool by such a
person as Skybuck - - maybe I can even win the award from Rudy - -
Now that is a more interesting contest - - - what do you say Rudy?
>
> Bye,
> Skybuck.
>
>
>
Jim P
bit test
so why worry about which is the fastest. - - - - -
Jim P.
Skybuck Flying
> In news:enp19b$4r1$1...@news5.zwoll1.ov.home.nl,
> Skybuck Flying <sp...@hotmail.com> typed:
>
>> "Dunny" <paul....@ntlworld.com> wrote in message
>> news:MCTnh.14573$Wy6....@newsfe1-win.ntli.net...
>>> In news:enovug$lv6$1...@news5.zwoll1.ov.home.nl,
>>> Skybuck Flying <sp...@hotmail.com> typed:
>>>
>>>> Jim P. is a troll and always looks like a fool.
>>>>
>>>> I urge you to make an implementation otherwise you will also look
>>>> like fools just like Jim P. at the end of this contest.
>>>
>>> It seems to me that writing your application for you would make
>>> anyone look like a fool.
>>
>> Oh look it's Dunny the fool.
>>
>> Dunny the fool whole believes a single BTS instruction is faster than
>> multiple different instructions.
>
> And where did I say that BTS was faster? Come on, a google-groups url will
> do as proof.
Exactly, if you only googled before you openened your nasty mouth ;)
"
Okay, although the bitwise operators will not be quite as fast as dedicated
x86 instructions for setting/resetting bits, won't they be more than fast
enough for anything he wants to do?
"
"
I'm no assembly "expert" like others around here, but wrapping a single x86
instruction around a CALL/RET pairing seems a bit daft, imo.
"
> I might even have mentioned that I use bitwise operators (xor, or, and) in
> my own code. Can't say I've ever used BTS! In fact, what I actually said
> was that the delphi bitwise operators might be slower than their
> single-instruction asm equivalents. Knowing how Delphi's compiler works,
> it's quite probable.
To speak in your own words:
"Get a clue"
Delphi has no bitset instruction to set a bit in memory.
You will have to combine delphi's bitwise operators and other instructions
to do so,
that's what this contest is about.
You need to develop your own algorithm/instructions sequence.
> I think that you're getting pissed because your ruse to get others to
> write code for you has been rumbled...
I think that's what you would like to believe.
Your lack of understanding is showing.
I doubt you could even write a bitset instruction yourself ! :)
Bye,
Skybuck.
Skybuck Flying
"Bodhi" <bo...@dharma.net> wrote in message
news:b_mdnZQdW92jmj3Y...@giganews.com...
You might a fool quite nicely out of yourself Bodhi by claiming that Delphi
has a bitset instruction ;)
Bye,
Skybuck.
Skybuck Flying
> Skybuck Flying wrote:
>
>> Jim P. is a troll and always looks like a fool.
>>
>> I urge you to make an implementation otherwise you will also look like
>> fools just like Jim P. at the end of this contest.
>>
>> Bye,
>> Skybuck.
> Hum that is an interesting comment - - - - am I really
>
> Look at all of the other peoples responses to you - - - -
> that answers it properly
>
> and Skybuck - - you do not even know when you are looking like the fool
>
> Just like in Sept - - when you keep pushing that crazy Idea of yours. - -
You looked like a fool on September, get your facts straightened out.
I'm done with your trolling.
And I will not let you ruin my contests ever, nice try though.
<snip>
Bye,
Skybuck.
Skybuck Flying
This is a newsgroup about Delphi.
Post some Delphi code or fuck off ;)
Bye,
Skybuck.
Bodhi
> You might a fool quite nicely out of yourself Bodhi by claiming that Delphi
> has a bitset instruction ;)
>
I'm assuming you left out the word "make" between "might" and "a".
But, why would I claim anything about Delphi? I know nothing about it.
And what does having "a bitset instruction" in Delphi have to do with
anything I've said to you prior to this?
You're losing it, Flysuck. And you know it, too.
Skybuck Flying
> Skybuck Flying wrote:
>
>> You might a fool quite nicely out of yourself Bodhi by claiming that
>> Delphi has a bitset instruction ;)
>>
Typo corrected:
might = make.
> I'm assuming you left out the word "make" between "might" and "a".
You wish.
> But, why would I claim anything about Delphi? I know nothing about it. And
> what does having "a bitset instruction" in Delphi have to do with anything
> I've said to you prior to this?
Ok, the thruth has come out.
You know nothing about Delphi.
Case closed.
Bye,
Bye, you nitwitt LOL
Skybuck.
Skybuck Flying
> than this one instruction - - wow - - - -
That's what the benchmarks are showing.
>>
>> You should have done a Google on BTS instructions Dunny the fool.
>>
>> If you had Googled for BTS instruction you would learned that it is well
>> known among assembler programmers that BTS is slow.
>>
>
> So I googled BTS - - - 'Intel Pentium BTS instruction' ---
>
> did not find what skybuck says that he found - - -
Keep searching :)
> what I found is some timing information - - the BTS instruction takes
> between 7 and 13 clocks depending upon location and indexing (Register or
> memory or indexed)
>
> Note the AND and OR and XOR instructions are faster if you have a bit
> pattern - -- the BTS, BTR, BT use a bit offset (position) that must be
> converted into bit position - - - if you do not have a pattern then the
> creation or getting of the pattern takes additional processor instructions
> and clock cycles.
>
> a move instruction depending upon the locations (Register to Register or
> Memory location indexed to Memory location indexed ) varied from 3 clocks
> to 22 clocks.
>
> so Skybuck - - I have a contest for you - - - to find an assembler level
> coding that is faster than BTS or BTR or BT to test or set or clear a bit
> in a memory location - - - -
Fair enough.
Here is my assembler code which during the benchmark is faster than BTS.
procedure SetBit_8bitv10( BaseAddress : pointer; BitIndex : byte ); //
fastest
begin
asm
// calculate byte position (bit index div 8) in dh
// store BitIndex in ecx and zero the rest
movzx ecx, dl
// divide BitIndex by 8
shr cl,$03
// add byte position to eax
add eax, ecx
// calculate bit position (bit index mod 8)
// store BitIndex in cl
mov cl, dl
// calculate BitPosition and store in cl
and cl,$07
// calculate and store mask in dh
// store 1 in dh
mov dh,$00000001
// shl dh with cl
shl dh,cl
// or content byte and mask together
or [eax], dh
end;
end;
Here is the BTS version, pretty efficiently implemented as you can see.
procedure SetBit_8bitv6( BaseAddress : pointer; BitIndex : byte );
begin
asm
bts [eax], edx
end;
end;
Now you can go put your teeth into this eh ;)
Bye,
Skybuck =D
Skybuck Flying
> Skybuck Flying wrote:
>> In case MMX instructions can also speed it up here is a possible MMX
>> prototype:
>>
>> procedure SetFourBits_8bit(
>> BaseAddress1 : pointer; BitIndex1 : byte;
>> BaseAddress2 : pointer; BitIndex2 : byte;
>> BaseAddress3 : pointer; BitIndex3 : byte;
>> BaseAddress4 : pointer; BitIndex4 : byte );
>>
>> etc...
>>
>> Bye,
>> Skybuck.
> again the calling and return code takes way more time than the actual bit
> test
<nonsense snipped>
:)
Bye,
Skybuck.
Skybuck Flying
>> In case MMX instructions can also speed it up here is a possible MMX
>> prototype:
>>
>> procedure SetFourBits_8bit(
>> BaseAddress1 : pointer; BitIndex1 : byte;
>> BaseAddress2 : pointer; BitIndex2 : byte;
>> BaseAddress3 : pointer; BitIndex3 : byte;
>> BaseAddress4 : pointer; BitIndex4 : byte );
>>
>> etc...
>>
>> Bye,
>> Skybuck.
> again the calling and return code takes way more time than the actual bit
> test
Jim, try to understand that for all the non-mmx versions the calling/return
overhead is the same.
Jim, try to understand that for all the mmx versions the calling/return
overhead is the same.
Jim, try to understand the calling and return overhead is a constant factor
and is irrelevant.
Jim, try to grasp the concept of inlining.
Jim, try to understand why inlining does not always generate faster code.
Jim, try to understand that the mmx version could be faster because it sets
4 bits with a single instructions (multiple data) (SIMD).
Jim, however the mmx version might have more calling overhead than the
non-mxx version, this is to be tested.
Jim, try to understand that maybe I do not want a single *assembler*
instruction in my *Delphi* code.
Jim, try to understand BTS is not supported on 286 ;)
Jim, try to understand BTS is slower than assembler algorithm :)
Jim, GET A CLUE LOL.
Jim, just get with the *Skybuck program*
Jim, try to understand the *trial and error* concept.
Jim, try to understand the usefullness of simple testing the practice
instead of trying to understand the complex theory.
Jim, try to understand the concept of *practice* = testing the theory and
discovering the thruth.
Jim, try to understand that different versions are interesting.
Jim, try to understand that knowing slow implementations is interesting as
well.
Jim, try to understand that analyzing compiler output is interesting as
well.
Jim, try to understand that I could go on and on and on and on with these
arguments...
Bye,
Skybuck ;)
Bodhi
> Typo corrected:
>
> might = make.
>> I'm assuming you left out the word "make" between "might" and "a".
>
> You wish.
>
>> But, why would I claim anything about Delphi? I know nothing about it. And
>> what does having "a bitset instruction" in Delphi have to do with anything
>> I've said to you prior to this?
>
> Ok, the thruth has come out.
>
> You know nothing about Delphi.
The "thruth" has always been out. I was the one that asked why you were
posting the same question in alt.comp.lang.borland-delphi and
alt.lang.asm. Rudy was nice enough to inform me that Delphi has a
built-in assembler. The context of that post alone would have alerted
even the simplest-minded person that I knew nothing about Delphi.
> Case closed.
Yes, whatever "case" you're referring to, it is closed. But only because
I don't want to embarrass you in front of everybody anymore. Having a
debate, or even a discussion with you is non-challenging. You are too
easily defeatable.
Dunny
Skybuck Flying <sp...@hotmail.com> typed:
> To speak in your own words:
>
> "Get a clue"
>
> Delphi has no bitset instruction to set a bit in memory.
Wrong - AND, OR, XOR, NOT.
> You will have to combine delphi's bitwise operators and other
> instructions to do so,
Ah, so you're saying now that Delphi *does* have bitset/unset/test
instructions now?
D.
Skybuck Flying
The only one you are embarrassing is yourself LOL.
Bye,
Skybuck =D
Bodhi
>
> The only one you are embarrassing is yourself LOL.
>
Like I said, "You are too easily defeatable."
Now go take your medication.
Jamie
> Jim P. is a troll and always looks like a fool.
>
> I urge you to make an implementation otherwise you will also look like fools
> just like Jim P. at the end of this contest.
>
> Bye,
> Skybuck.
>
>
educate you, sure isn't doing your image any good. That is,
if you every had one to start with.
--
"I'm never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5
Skybuck Flying
performance of any code, and therefore it must be benchmarked !
That's exactly what I set out to do during this contest. (Fast Bit
Operations Contest) (and have been doing for many years now)
Even the manuals I mentioned mention the misleading character of the
information.
Yet you claim to somehow know that BTS would be faster than anything else.
What do you base your claims on ?
You mentioned clock ticks etc.
Again nonsense and other bullshit.
You once again have made a fool out of yourself Jim !
Bye,
Skybuck.
Jim P
> "Jim P" <Ji...@mad.scientist.com> wrote in message
> news:1vmdnfV0V7jzrT3Y...@comcast.com...
>
>>Skybuck Flying wrote:
>>
>>>In case MMX instructions can also speed it up here is a possible MMX
>>>prototype:
>>>
>>>procedure SetFourBits_8bit(
>>> BaseAddress1 : pointer; BitIndex1 : byte;
>>> BaseAddress2 : pointer; BitIndex2 : byte;
>>> BaseAddress3 : pointer; BitIndex3 : byte;
>>> BaseAddress4 : pointer; BitIndex4 : byte );
>>>
>>>etc...
>>>
>>>Bye,
>>> Skybuck.
>>
>>again the calling and return code takes way more time than the actual bit
>>test
>
>
> Jim, try to understand that for all the non-mmx versions the calling/return
> overhead is the same.
>
> Jim, try to understand that for all the mmx versions the calling/return
> overhead is the same.
>
> Jim, try to understand the calling and return overhead is a constant factor
> and is irrelevant.
Skybuck - - on earlier processors this was true but on a multi-processor
processor with cache - - this is not true - - depends upon a lot of
things. many variables that have to be considered that seem to be beyond
you level of concept
>
> Jim, try to grasp the concept of inlining.
>
> Jim, try to understand why inlining does not always generate faster code.
>
lets see the test that you did a while ago was so bogus and lack of
understanding of processor cache L1 and L2 and the constraints resulting
from that
You inlined a whole program - - and of course the code size blew up - -
this caused the cache to have very few hits and was swapping out of main
memory a lot more - - so you crippled the cache and its benefits by
doing this.
The inlining helps small routines that need to be fast - - - a large
routine with lots of clock cycles -- there is very little to gain
This said to you then - - - - -
the code size increase from inlining slows the program down - - on cache
based systems -- which all current PC's are - - - -
as soon as the code loop is larger than the cache - - this occurs. That
was stated to you then.
Now Inlining does not always increase the size of the resulting code.
In the case of the bitset operation - - on Processor instruction - -
the overhead of the calling and return a lot more code than the actual
code that does the operation - - - so each time it is called more code
is added than if it was inlined.
This was stated to you while you were doing your inline testing and we
were trying to let you know that your testing was testing not what you
wanted it to test.
So just like any function or tool it can be used wrong and no benefit is
present from the use of the tool - - -
You applied the inline function wrong and got what most of us would say
was the expected result -- - inline everything the code blows up -- - -
that is why procedures and Functions were developed. - - and on cache
based machines - - cache hit ratio drops greatly - - - so what do you
expect to happen -- - it runs slower -- -
and in procedures and functions that more than a few hundred cpu clock
cycles are needed - - - very little is to be gained. - - very little
it was added to aid in the simple little function and procedure calls.
Such as the bit test - - or other small code routines - - - - -
again this was explained to you and you refused to listen and stop and
realize what you are being told. - - - - and then do test based upon
this new information to see what the effect really is.
In other words --- a procedure or function with 100's of lines of code
the benefit from inlining is basically nothing - - - a 1 to 3 lines of
code the translates into only a small amount of machine code - - it
helps --- and can speed things up greatly by not having the calling code.
> Jim, try to understand that the mmx version could be faster because it sets
> 4 bits with a single instructions (multiple data) (SIMD).
>
> Jim, however the mmx version might have more calling overhead than the
> non-mxx version, this is to be tested.
>
> Jim, try to understand that maybe I do not want a single *assembler*
> instruction in my *Delphi* code.
>
ah - - why keep the others from doing it --you asked for the fastest and
got insulting over the fastest way - - -
> Jim, try to understand BTS is not supported on 286 ;)
>
and when is the last time that you have seen a 286 computer? or a 386
computer or a 486 computer - - - - - so who the hell cares about a 286.
> Jim, try to understand BTS is slower than assembler algorithm :)
Really -- prove it - - -
>
> Jim, GET A CLUE LOL.
>
> Jim, just get with the *Skybuck program*
Why? when it is so crazy and out of whack
>
> Jim, try to understand the *trial and error* concept.
>
Oh I do that all the time in my code - - -
> Jim, try to understand the usefullness of simple testing the practice
> instead of trying to understand the complex theory.
>
and when someone points out to you the problem with your test - - you
get upset - - as it is pointed out to you that the test you are trying
to perform has more variables than you are taking into account and thus
the test results are not going to be valid - - - some of us have learned
that the hard way - - be sure to control the variables - - if all
variables are not controlled the test results most likely will not be
valid or giving false and not valid results. - - it might look like this
but you are realling seeing the effect of a variable that you did not
take into account - - - - - and we try to point that out to you and you
simply get nasty in return -- -call us fools -- insult us in many ways -
- just because you do not what to hear or be helped. - - - - and then
wonder why we respond the way that we do - - - and then you claim we
insulted you first in response to our replay you insulting us - - one
look at the thread and it is clear - - you did the first insult - - - -
and then expect us to have respect and believe what you said -- when you
argue that you did not insult first - - while the thread clearly shows
that you did - - - - - where is the truth - - and honestly - - - -
where is the respect that we all want each other to give to each other -
- while you are doing this - - - - where - - - -
> Jim, try to understand the concept of *practice* = testing the theory and
> discovering the thruth.
and that also means that you should listen to others as they point
things out to you instead of simply getting mad at them and insisting
upon still running the same test - - in ways that are not valid or
listen to others that might know more than you and are trying to teach
and explain to you - - - and you then get insulting and calling them
fools - - and wonder why people look at you as crazy --you insult first
and then get mad when you get insulted in response. - - - - and refuse
to stop and listen - -
>
> Jim, try to understand that different versions are interesting.
>
Yes that can be true - - but you have to understand that we are
practical people and work for a living and get things done -- and in
practical - - if one way or an other is not going to make a difference
in speed or code size enough to be noticed or measurable -- who cares? -
- - we have more important things to be concerned about and find
interesting. - - -
> Jim, try to understand that knowing slow implementations is interesting as
> well.
>
Yes, but we have jobs to do - - work to perform - - we do not get paid
to explore all of the slow methods to do a simple task - - - why should
we. we have jobs and work to do - - -
> Jim, try to understand that analyzing compiler output is interesting as
> well.
and I ask you to do that to see what the overhead of a procedure is and
the amount of code that is needed for the different methods - - - and
the amount of instruction cycles that are needed for each method -- if
you did this - you would see the amount of code in the calling routines
and can compare that to the effects of inlining small routines compared
to larger routines and learn what we are trying to teach you.
>
> Jim, try to understand that I could go on and on and on and on with these
> arguments...
and you go on and on and not listen or learn - - you preach facts that
you learned by improper testing - -- - and never stop to listen to what
others are telling you - - - - -
But do you have to put each and every one of your thought processes for
us to look at and review and think about - - it would be boring if I
was to do the same thing with the code that I am doing right now with
turbo explore -- -with the storage of records in Tstringlist - -
basically arrays of strings and the strings can be an additional
stringlists, and these can also be Tstringlists - - and the performance
and benefits of this. - - - the using Valuelisteditors and stringgrids
for display and data entry - - - of different of the stringlists. Did
this for an other project a year ago and now expanding upon it an
improving it as I have learned more about delphi and what you can do
with it in the last two years. - - - what if everyone of us did this. -
- - -
Would the whole newsgroup be interested in my hourly post of what i am
finding out as I do this and the troubles that I have -- the trial and
error process - - - - or brag about how fast this is and - - - and -
-and fill this newsgroup up and others over this - - -- - - oh wow -
world look at what I found out - - - oh wow - -
Jim P.
>
> Bye,
> Skybuck ;)
>
>
Skybuck Flying
You are the one easily defeatable because you know nothing about Delphi.
That much you have shown.
And you even said so yourself LOL.
You would even loose a debat with yourself LOL.
I don't need to be debating with you.
You automatically loose hahahahaha
Bye,
Skybuck.
Skybuck Flying
"Jamie" <jamie_ka1lpa_not_v...@charter.net> wrote in message
news:%UXnh.401$gZ2...@newsfe04.lga...
> Skybuck Flying wrote:
>> Jim P. is a troll and always looks like a fool.
>>
>> I urge you to make an implementation otherwise you will also look like
>> fools just like Jim P. at the end of this contest.
>>
>> Bye,
>> Skybuck.
> You know Skybuck, your method of getting people to
> educate you, sure isn't doing your image any good. That is,
> if you every had one to start with.
I am educating you, you have things reversed =D
You probably stuff food up your anus as well LOL.
You seem to have many things reversed hahahaha.
Bye,
Skybuck.
Jamie
Prove it..
You're a smuck, the additional set up required to generate an
bit image to use the well known xor, and etc. functions that take
less CPU cycles, and i may add! because they don't perform any
setup!, Setup, SetUp !!!!!!!!!!!!!!!!!! prior too!!!!!!!!!!!!!
get it moron.!!!!!!!!!
With today's processors, especially the new ones, i can assure you
that if you calculate total setup of creating a mask image compared to
how the CPU performs that doing a BTS instruction! You'll find that
the BTS wins.
The only time it does not is if you may already have some value for
a mask set up in the chain of registers other wise, the CPU fetching
process along with the execution of performing the single steps that
leads up to the final logic instruction, is going to total more than the
BTS does.
Jim P
That has been true for decades - - - for timings are based upon a
certain clock speed.
Why change the instruction manual for each processor speed upgrade
to reflect the different times - - why not give them as clock cycles.
see your other post. for what I base it upon
Jim P.
Bodhi
> You are the one easily defeatable because you know nothing about Delphi.
>
> That much you have shown.
>
> And you even said so yourself LOL.
>
> You would even loose a debat with yourself LOL.
>
> I don't need to be debating with you.
>
> You automatically loose hahahahaha
Alright, I'm starting to get a guilty conscience here. The kind one gets
when they find out they've been taunting a "mentally-challenged" person.
I'll really start to feel that way, if you respond to this by saying
that I'm "mentally-challenged".
The proverbial ball is now in your court, Mr. Flying.
Jim P
Like I said - - - always ready to confront and argue - - - never to stop
and learn and listen
Jim P.
Skybuck Flying
Let's take the nonsense from Intel's Optimization Manual and apply it to the
codes:
Skybuck's Own Assembler version:
// missing in manual probably the same as movzw
movzx ecx, dl
latency: 1
shr cl,$03
latency: 1
add eax, ecx
latency: 1
mov cl, dl
latency: 1
and cl,$07
latency: 1
mov dh,$00000001
latency: 1
shl dh,cl
latency: 1
or [eax], dh
latency: 1
Total latency: 8
Skybuck's BTS version:
bts [eax], edx
latency: 8 to 9
There you have it folks.
Latency is about the same.
However that's not the entire story.
Skybuck's Own Assembler version can execute multiple instructions at the
same time.
This is called "pairing" on the pentium processors...
And the newer processors have micro operations etc.
So it's quite possible Skybuck's Own Assembler version gets partially
executed in parallel.
Which could explain the higher speed ;)
How it exactly works I dont know yet :)
That's where the benchmark comes in :)
Bye,
Skybuck. =D
Jim P
Skybuck if educating is what you are doing -- forget it.
you provide very little meaning full information - - you do a lot of
bogus test that prove nothing because you do not understanding what you
are testing.
Your arguemnents about scrollbars and needing more resolution is more
proof of this - - - what if you have a 100 million line file - - and if
I do have that that I will look at solutions -- I have had 10,000 line
Stringgrids and the present scrollbar worked just fine - - - but you
always have to find something and then push it to the limit just to
prove your point and need for it.
Just like your idea - - in sept -- you seemed to have disappeared for a
while after that - - - - when you started pushing harder and harder to
show and advantage to your idea - - what if it was this amount of
information - - 100's of megs, - - oh ok 100's gig's to millions of
people and when the actual cost was pointed out to send by ISP and the
problems in your concept you exploded and insisted on trying to show it
was valid - - - even to the point of not understanding that to send that
amount of data out of a PC over cable is limited by the upload speed
that is a lot slower than download speeds. My Comcast download is 6 meg
bits while the upload is 400K bits or 40K bytes per second - - - so 100
meg is going to take how many hours to transmit - - - Ouch and you
expect your customers to want to have you take over their computers and
send this information to others -- -
and people started realizing - - why collect this much information and
provide it free - - 1 million people -- charge them $1 each - -per month
a more than fair deal - - - make some money for your time to collect
this much each Month - - and for the people that will be needed to help
collect this much each month to be sent out ---- - - and you exploded
over these comments - - - - - -
we are trying to help you and think that you are all knowing and if
someone says - - what about this and what about that --you simply attack
them - - -
Jim P.
Jim P
Correct - - that is why they added the instruction - - - if two
instructions or 3 was faster why would they waste the time and effort to
add the instruction - - - - -
Jim P.
Jim P
so now you are past the point of calling me a fool
and have degraded to more insulting terms - - -
and I was trying to win the fool award.
Why should I code a one line assembler instruction
Jim P.
Dunny
Skybuck Flying <sp...@hotmail.com> typed:
I'm certainly no asm expert (my speciality is Delphi) but this...
> movzx ecx, dl
> shr cl,$03
Won't pair.
> add eax, ecx
> mov cl, dl
Neither will these.
> and cl,$07
> mov dh,$00000001
These might, but I'm not so sure, depends if the above mov cl,dl has
completed.
> shl dh,cl
> or [eax], dh
Won't pair.
> Skybuck's Own Assembler version can execute multiple instructions at
> the same time.
>
> This is called "pairing" on the pentium processors...
> So it's quite possible Skybuck's Own Assembler version gets partially
> executed in parallel.
Partially *possibly*. I'd like the denizens of alt.lang.asm to confirm if
I'm right or not.
Folks?
D.
Jim P
Wow you just proved my point even if you assumed that each of your
assembly instructions
only took one clock cycle - - there are 8 assembly instructions in your
code
for the bit set only 7 clock cycles - - - need I say any more
many of the above assembly instructions take 2 or 3 clock cycles - - the
min move clcok cycles is 3 and 3 mov instructions are present for 9
clock cycles -- and then we still have the times for the other 5
instructions.
and not counting all the coding time and effort and resulting debugging
time and also the additional code size. - - - - - - -
Like I said may times - you do not stop and listen and only argue to
prove your point and never listen and see what others are saying -- you
must always be right -- - and never desire to learn ---- -
One instruction is not a faster then 9 instructions. - - - is that what
you are saying and trying to prove. - - - - and you wonder why people
wonder about you - - you argue simply to argue -- - - - - not to find
out or learn or think - - but to keep proving the same point that has
been debated and argued more than enough - - and you are the only one
that refuses to understand this and how you come off.
It is no wonder you do not like Moderated groups -- they ban you - - -
Jim P.
Jamie
Hmm, really? The last time i got up from the toilet seat while
looking down to inspect my handy work, I swear I saw you staring back at
me! Hope you didn't hit the water too hard!. I wouldn't want
to see any one get hurt now.
Skybuck Flying
manual, since timings can be different depending on memory and registers..
so maybe later I will redo it... but since I don't have a pentium 4 and only
a pentium III... it's not that much interesting for me.
What is interesting is the speed on X2 3800+ because that's what I am using
at the moment to benchmark it. Later I will also benchmark on my Pentium
III, Pentium 1 and 80486 ;)
So now I will take a close look at the "Software Optimization Guide for
AMD64 Processors" manual which also includes latency figures... and this
time I take a close look to represent it as closely as possible, (since
there is no X2 manual I think this manual has to be applied):
Skybuck's Own Assembler version:
movzx ecx, dl (reg32, mreg8)
latency: 1
shr cl,$03 (mreg8, imm8)
latency: 1
add eax, ecx (reg32 or mreg32(?), reg32 or mreg32(?) (doesnt matter for
latency))
latency: 1
mov cl, dl (reg8 or mreg8, reg8 or mreg8)
latency: 1
and cl,$07 (mreg8, imm8)
latency: 1
mov dh,$00000001 (dh, imm8)
latency: 1
shl dh,cl (mreg8, CL)
latency: 1
or [eax], dh (mreg8 or mem8(?), reg8)
latency: probably 4 for mem8 or 1 for mreg8
Total latency: 8 or 11
Skybuck's BTS version:
bts [eax], edx (mem32 or mreg32 (?), reg32)
latency: probably 9 for mem32 or 2 for mreg32.
So 8 or 11 versus 9 or 2.
It's probably 11 versus 9.
Which would mean my own version would be slower than BTS... but:
1. I could be wrong about the "or" latency which could be total 8.
2. Or AMD64 has pairing and stuff like that or other tricks which make my
own version faster in the end ;)
Bye,
Skybuck.
Jim P
> Just for kicks,
>
> Let's take the nonsense from Intel's Optimization Manual and apply it to the
> codes:
>
> Skybuck's Own Assembler version:
>
> // missing in manual probably the same as movzw
> movzx ecx, dl
> latency: 1
somewhere in here has to be the fetch of the bit index so a memory
operation is needed here -- and some time has to be added for that.
>
> shr cl,$03 ---
> latency: 1
>
on most processors an immediate requires some additional time
assuming on pentiums also - - as additional bytes have to be fetched.
> add eax, ecx
> latency: 1
>
> mov cl, dl
> latency: 1
>
> and cl,$07
> latency: 1
again are extra bytes required for immediate addressing
> mov dh,$00000001
> latency: 1
again are extra bytes required for immediate addressing
>
> shl dh,cl
> latency: 1
>
> or [eax], dh
> latency: 1
>
this if I have my understanding of Intel assembler means a memory
operation so add some here
> Total latency: 8
>
> Skybuck's BTS version:
>
> bts [eax], edx
> latency: 8 to 9
>
> There you have it folks.
>
> Latency is about the same.
>
not really - - if I have my understanding correct.
> However that's not the entire story.
>
> Skybuck's Own Assembler version can execute multiple instructions at the
> same time.
but that is only if the second instruction does not depend upon the
results of the first being finished --- - it can not process a result if
does not have the result to process.
>
> This is called "pairing" on the pentium processors...
>
> And the newer processors have micro operations etc.
>
> So it's quite possible Skybuck's Own Assembler version gets partially
> executed in parallel.
and from what is said before - - - can not start a processing of an
instruction if the result of the prior instruction is not present.
>
> Which could explain the higher speed ;)
and if not - - - -
>
> How it exactly works I dont know yet :)
>
and will you ever
> That's where the benchmark comes in :)
and if you do not do the benchmark corretly -- you will not be testing
what you think you are testing - - - - right
Jim P.
>
> Bye,
> Skybuck. =D
>
>
Jim P
> Skybuck Flying wrote:
>
>> "Jamie" <jamie_ka1lpa_not_v...@charter.net> wrote in
>> message news:%UXnh.401$gZ2...@newsfe04.lga...
>>
>>> Skybuck Flying wrote:
>>>
>>>> Jim P. is a troll and always looks like a fool.
>>>>
>>>> I urge you to make an implementation otherwise you will also look
>>>> like fools just like Jim P. at the end of this contest.
>>>>
>>>> Bye,
>>>> Skybuck.
>>>
>>>
>>> You know Skybuck, your method of getting people to
>>> educate you, sure isn't doing your image any good. That is,
>>> if you every had one to start with.
>>
>>
>>
>> I am educating you, you have things reversed =D
>>
>> You probably stuff food up your anus as well LOL.
>>
>> You seem to have many things reversed hahahaha.
>>
>> Bye,
>> Skybuck.
>>
>>
> Hmm, really? The last time i got up from the toilet seat while
> looking down to inspect my handy work, I swear I saw you staring back at
> me! Hope you didn't hit the water too hard!. I wouldn't want
> to see any one get hurt now.
>
>
>
>
Good one
Jim P.
Terry Russell
> Skybuck Flying wrote:
> Please show me the proof --- you say so much BS that it is hard to take
> anything that you say at face value
>
> so the code and the timing results - - computer and memory access
> types - - - make it a fair test - - - - -
>
>
> It is hard to believe that a single instruction is slower than a couple of
> instructions --- simply the time for the instruction fetch and decode is
> most of the clock cycles - - - - - and by the time you do 2 or 3 simple
> instructions - simply the cycles required for instruction fetch and decode
> is going to be more than the total clock cycles for 2 or 3
> instructions - - - Assuming that the location is not in a register - - as
> you are interested in this being for huge chucks of memory - - -
'The Search for the 2-bit unicycle'
aka
'I lost it over there but I am looking here because the light is better'
A cpu tick is a picocent resource, memory is microcents per byte (once),
developer time is a kilobuck a day. The code is useful to the user,
time without code costs user.
The most efficient thing for you, your family , the users and the world
would be to just block sender and move on.