Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / recognition of empty line: fast, faster and fastest

Author
Message
Scary Little Rabbit
15
Years of Service
User Offline
Joined: 4th Aug 2009
Location: Chelyabinsk, Russian Federation.
Posted: 25th Mar 2014 04:02
sometimes it is starts like this: if len( s$ ) > 0... do you dance it this way? looks like you have full amount of endless time in your pocket.

let's twist again:


push the tempo.

error #1:
"too many stars, too many stares. disembody."
WIP: MIND!! | free fonts for your AGKs
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 25th Mar 2014 08:13
yeahh, my question was why seems
if s[ n ] <> ""
faster than
if len( s[ n ] ) > 0

AGK 108 (B)19 : Windows 8.1 Pro 64 Bit : AMD Radeon HD 6670
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 25th Mar 2014 08:31
I have absolutely no idea what you're trying to say

Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 25th Mar 2014 08:51
So Len(s$)>0 is faster than s$<>"" ?

That's interesting... might just be the way the engine handles strings, like maybe it has to do some housework before it can check a string, but the length of the string is probably separate from that.

I am the one who knocks...
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 25th Mar 2014 09:25
@Van B
no, it seems s$<>"" is faster than Len(s$)>0
i ever thought that Len(s$)>0 is faster because value compare.

AGK 108 (B)19 : Windows 8.1 Pro 64 Bit : AMD Radeon HD 6670
Scary Little Rabbit
15
Years of Service
User Offline
Joined: 4th Aug 2009
Location: Chelyabinsk, Russian Federation.
Posted: 25th Mar 2014 09:35
Phaelax, just run the code and say your results to us.

Van B, in my tests if s[ n ] = "" else do_some endif is fastest way.

are there people who know what and why core does?

error #1:
"too many stars, too many stares. disembody."
WIP: MIND!! | free fonts for your AGKs
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 25th Mar 2014 12:28
There are different ways of storing strings. These are null-terminated, so doing a count requires scanning and counting. <>"" simply looks at the first char and if it's null it returns true, otherwise it returns false. It does not need a variable to store the count, and is faster.

-- Jim - When is there going to be a release?
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 25th Mar 2014 13:05
hmm, that means my string can not have a char(0) at first.
in agk chr(0) did not response a String with one char.
means i can not use chars from 0-255.
(its unimportant, also inconsequent, just c++ special)

AGK 108 (B)19 : Windows 8.1 Pro 64 Bit : AMD Radeon HD 6670
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 25th Mar 2014 19:58
len( s[ n ] ) > 0 174-215 (about 190 average)
s[ n ] <> "" 120
s[ n ] = "" 90

What's weird to me is how len was constantly changing speed.

Impetus73
13
Years of Service
User Offline
Joined: 28th Aug 2011
Location: Volda, Norway
Posted: 26th Mar 2014 13:41
The len() function needs a few CPU cycles to run, compared with "" that takes 1 cycle, I think.

Calling a function, instead of providing a static string, must be slower, only logical. the program has to jump to another location in memory, start running there, provide data, process data, return data, and go back to the next address before the jump, this takes time.

----------------
AGK programmer
Did Amiga / AMOS programming in the 90's.
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 30th Mar 2014 22:33
You CANNOT use char #0 in null-terminated strings. Ever.

-- Jim - When is there going to be a release?
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 1st Apr 2014 14:46
What Impetus73 said plus...

<> "" : 2 operations (less than, followed by greater than)
= "" : 1 operation

Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 1st Apr 2014 16:01
Quote: "
<> "" : 2 operations (less than, followed by greater than)
= "" : 1 operation
"


equality and inequality between strings only needs a single operation.

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 2nd Apr 2014 04:51
Quote: "<> "" : 2 operations (less than, followed by greater than)"

That doesn't sound right. The compiler should be interpreting '<>' as 'not equals'.

Quote: "equality and inequality between strings only needs a single operation."

Not quite. In both cases, it is necessary to at least start looking at the contents of each string. In both cases, if a non-matching character occurs, the comparison stops. But, potentially, every character in the two strings must be checked. This involves two fetches (one for each string) and one comparison for every character in the string. Sometimes a string checking process can do a fast non-equality check based on string length. If the two lengths are different, then they obviously aren't equal.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 2nd Apr 2014 10:58
I think I'm confusing it with >=, which is two operations.

Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 2nd Apr 2014 11:25
@Ancient Lady

erm... thanks i guess, but your running off on a tangent..



@BatVink

Quote: "which is two operations."


Nah doesn't need two separate operations/passes either, as at character level string compares are nothing more byte/integer compares. Every time you compare, the operation sets the condition codes accordingly, so equality, less & greater than. You just branch on the combo you want.

BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 2nd Apr 2014 15:15
Quote: "Every time you compare, the operation sets the condition codes accordingly, so equality, less & greater than. You just branch on the combo you want."


That's useful to know, things have changed since my IBM training many years ago! I guess there must be some clever algorithms setting all three flags to prevent every calculation being overburdened with the checks you aren't interested in.

Marl
13
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 2nd Apr 2014 17:18
Quote: "I guess there must be some clever algorithms setting all three flags to prevent every calculation being overburdened with the checks you aren't interested in."

(useless trivia)
Back in the old days, the cpu performed a passive subtract operation - passive in that the result is not used - which set flag bits based on the (imaginary) result;
- The Zero bit - if the 2 numbers were equal
- The Minus bit - if the second number was larger

These 2 bits were then used for four branch operations;
- Branch if Equal (branches when zero bit set)
- Branch if Not Equal (branches when zero bit clear)
- Branch if less than (branches when Minus bit set)
- Branch if greater than (branches when both bits clear)

There were other flags such the overflow bit and the carry bit to add to the mix, but I've bored you enough already
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 2nd Apr 2014 19:05
As I said above, empty string tests are very fast. The empty string is a special case.

-- Jim - When is there going to be a release?

Login to post a reply

Server time is: 2024-11-25 03:56:58
Your offset time is: 2024-11-25 03:56:58