posted August 05, 2006 05:29 AM            

Here is the tabular version. It runs about 10% faster, and is more
configurable. Not too bulky either.

I have appended it to the previous forum topic as
ParseTableDemo.zip
http://www.forum.it-berater.org/index.php?topic=158.0

The source for the short-jump version is also included in the zip
for posterity.

Thanks for all your comments and CPU performance data.
Further ideas very welcome.

posted August 05, 2006 05:40 AM            

Paul.

posted August 05, 2006 05:50 AM            

DIM bwi AS DWORD ' character position of word in the string
DIM lbi AS DWORD ' length of string
DIM ii AS DWORD ' next position after the end of the word
DIM testloops AS DWORD

to

DIM bwi AS LONG ' character position of word in the string
DIM lbi AS LONG ' length of string
DIM ii AS LONG ' next position after the end of the word
DIM testloops AS LONG

and jump from 24450 to 37790

For this reason I use DWORD only when interfacing with API functions.
In all other cases I always use LONG and only for this I've got a lot of speed
when inside big loops or many value assignments.

Regards

------------------
Eros Olmi
eros.olmi@thinbasic.com

posted August 05, 2006 06:28 AM            

The speed has jumped from 21000 to about 32000.
I am just trying to pinpoint the cause.
It might be something to do with the inner loop:

WHILE ii<=lbi
GOSUB zbword
WEND

because bwi does not make a difference whether LONG or DWORD

posted August 05, 2006 06:33 AM            

I remember Marco Pontello and others did an assembly comparison
between DWORD and LONG and found the reason why this was appening.

I'm not an ASM guy so I've no clue why.

Ciao

------------------
Eros Olmi
eros.olmi@thinbasic.com

posted August 05, 2006 06:42 AM            

Paul.

posted August 05, 2006 07:14 AM            

The speed has just gone up even further from 32000 to 36000 by
replacing the inner loop with assembler

ii=1
' WHILE ii<=lbi
' GOSUB zbword
' WEND

! push eax
loopz:
GOSUB zbword
! mov eax,ii
! cmp eax,lbi
! jle short loopz
! pop eax

You could try this with some of your code.

posted August 05, 2006 07:39 AM            

I know asm as nothing to do with it but instead how PB compiler handle it.
But to understand what's behind the curtains asm is needed in order
to see what code is added or is different to manage LONG vs DWORD.
And at this point ... I'm lost

Found something but not what I was remembering: http://www.powerbasic.com/support/forums/Forum4/HTML/009037.html

posted August 05, 2006 07:42 AM            

Thanks

posted August 05, 2006 07:57 AM            

I confirm what you say.

Just ii=1 seems to make a speed difference, when ii is a
DWORD instead of a LONG.

The speed penalty here is 34666 vs 36211 words/msec.

I have been puzzling how to further reduce the logic in the
parser. I am using 9 conditionals. 12 have been eliminated.

The lowest theoretical limit must be:
1 for string length checking
1 for quote markers
1 for leading space checking
1 for delimits.

2 tables required:
1 for self delimit
1 for non-self delimit

just thinking aloud...

posted August 05, 2006 09:32 AM            

Paul.

posted August 05, 2006 10:44 AM            

Dell PII/400 Mhz, Windows/98. Normal program mix, but did nothing whilst demo was running.

MCM

posted August 05, 2006 11:25 AM            

4490
124

posted August 05, 2006 02:34 PM            

Yes I can see how a set of jump tables would work. I think
four would be needed to provide equivalent functionality, which
considerably bulks out the code. (4k)

To make efficient use of pipelining I presume the jump tables
have to be adjacent to the rest of the code. To ensure this happens,
the assembled binary could be fed into an array with the jump tables.
and then called by DWORD.

posted August 05, 2006 04:28 PM            

for those like me not expert in ASM, what about to create it in a form of function?
Something like GetNextToken(byval StringPtr, byval StartPos, byref TokenStart, byref TokenLen)
This would be very useful for many I think.

Thanks a lot