A Very Small Fast Parser ( Assembly code) - PowerBASIC Forums

PowerBASIC Forums

Third-Party Addons

A Very Small Fast Parser ( Assembly code) (Page 1)

profile | register | preferences | faq | search

UBBFriend: Email This Page to Someone!
This topic is 4 pages long: 1 2 3 4

next newest topic | next oldest topic

Author	Topic: A Very Small Fast Parser ( Assembly code)
Charles Pegge Member	posted August 04, 2006 06:51 AM This parser is suitable for use in a script engine or for parsing any data strings that use symbols as well as words. Call it repeatedly to index sequential words and symbols in a text string. I have written it to accelerate my scripting language; the machine code is only 251 bytes long and on the demo test my PC pushes out about 19 million words per second. Since the code has a very simple structure (more Macaroni than Spaghetti) it is easy to adapt or extend. source including demo test: http://www.forum.it-berater.org/index.php?topic=158.0 faster,simpler or shorter assembler very welcome. ------------------ Charles IP: Logged
Roger Rines Member	posted August 04, 2006 11:25 AM quote: Originally posted by Charles Pegge: the demo test my PC pushes out about 19 million words per second. Hello Charles, That is impressive code speed and an amazing machine number. When I tested your demo here on two machines, machine #1 generated 13,874 and machine #2 generated 12,795 and I thought they were fairly fast machines. Can you share some information about the PC that generated that value as it may be time to upgrade my big machine? ------------------ Roger... (Mail to rdrines at Yahoo dot Com) IP: Logged
Peter Jinks Member	posted August 04, 2006 02:08 PM Hi Roger, The speeds you're seeing are on the same order of magnitude as Charles' stated figures. Charles states 19 million per second. The results shown in the program dialog are per millisecond. I just ran the program again to check this, and got a figure of 21,346 per millisecond, or just over 21 million per second. As you say, impressively fast! Regards, Pete. IP: Logged
Roger Rines Member	posted August 04, 2006 02:39 PM Hello Peter, Your machine is getting more done that Charles' reported. What about your machine, what makes it cook so fast? ------------------ Roger... (Mail to rdrines at Yahoo dot Com) IP: Logged
Peter Jinks Member	posted August 04, 2006 02:49 PM Hi Roger, Erm... my laptop machine is a Pentium-M @ 2.0GHz, with 2GB RAM, but beyond that I don't think there's anything that would make it particularly fast. I've just run the program again and got 19,817 per millisecond, so it clearly does vary a bit, but it's right around what Charles said. Just out of interest I also tried it on my desktop machine, which is an AMD-64 3500+ and it is hovering right around the 19-20 million figure as well. Both machines are running Windows XP Pro SP2, if that makes a difference. Regards, Pete. [This message has been edited by Peter Jinks (edited August 04, 2006).] IP: Logged
Marco Pontello Member	posted August 04, 2006 03:09 PM Just to provide some other data, I see 22.500 on an iMac (Intel Core 1.8GHz, 1.5GB, XP SP2). Bye! ------------------ Try Online TrID file identifier! Recognize over 2.100 filetypes and counting... ;) Give a powerfull scriptable Lua interface to your application with PowerBLua Leakout - Firewall outbound control tester - BitmapRip Extract/recover bitmaps from any file! IP: Logged
Eros Olmi Member	posted August 04, 2006 03:31 PM 24482 on a Centrino Duo 2GHz http://www.pcmag.com/article2/0,1895,1907007,00.asp ------------------ Eros Olmi eros.olmi@thinbasic.com [This message has been edited by Eros Olmi (edited August 04, 2006).] IP: Logged
Paul Dixon Member	posted August 04, 2006 03:56 PM Charles, quote: ' Another possibility is using short jumps instead of long jumps - but these are not supported ' by the PB assembler PB used to default to short jumps but this upset folk when the debugger made the compiled code longer and the short jumps were then out of range so code couldn't be run in the debugger. So it was changed to default to long jumps but you can still override the default by specifying a short jump like this: !jg short label1 Paul. ------------------ IP: Logged
Elias Montoya Member	posted August 04, 2006 04:35 PM Geez im always behind 12609 Pentium D 3.0 Ghz. 640MB ram. Eklias ------------------ Egrid32 Grid Control - Form Designer for Egrid32 - Print Engine for Egrid32 www.sweetheartgames.com - Visit the Forums! =) IP: Logged
Paul Dixon Member	posted August 04, 2006 05:42 PM Charles, quote: faster,simpler or shorter assembler very welcome. Modern CPUs prefer to avoid conditional jumps, especially on random data as this messes up the pipelines of the CPU. It's not too bad if the jump usually goes the same way as the CPU learns which way the jump is likely to go and takes that into account. It may take up 200 bytes more space but I think you'd get much faster code using lookup tables, you'd then avoid most of the jumps. It would also be much easier to alter which characters do what in a lookup table version. Paul. ------------------ IP: Logged
Roger Rines Member	posted August 04, 2006 05:54 PM Hmmm, Something doesn't compute for me on this. Machines here: ' Machine #1 -> 14,099 to 13,874 ' Dual 3.2GHz XEON, 800FSB, ' 2Gig Corsair Premium Memory (low latency), ' WinXP Pro SP2 Machine #2 -> 12,795 to 13,000 ' Single 3.4Ghz Prescott, ' 800FSB, ' 2Gig Corsair Permium Memory (low latency), ' Win2K Pro I wonder why the slower processors run through this faster than the faster CPUs can twiddle the bits? ------------------ Roger... (Mail to rdrines at Yahoo dot Com) IP: Logged
Michael Mattias Member	posted August 04, 2006 06:48 PM >I wonder why the slower processors run through this faster than >the faster CPUs can twiddle the bits? Different conditions, priorities, whatever. Multi-tasking system 'benchmarks' are not such a simple thing to test. You could probably get more accurate relative numbers by making them run in a thread with its priority set to THREAD_PRIORITY_REALTIME. That's more demanding of time than even the highest-maintenance girlfriend. But maybe we'll see if that's really true. I could run it on my screaming four-hundred megahertz (that's two-fifths of a single gigahertz) machine and see what numbers I get. IP: Logged
Charles Pegge Member	posted August 04, 2006 07:45 PM quote: PB used to default to short jumps but this upset folk when the debugger made the compiled code longer and the short jumps were then out of range so code couldn't be run in the debugger. So it was changed to default to long jumps but you can still override the default by specifying a short jump like this: Paul, Thanks for the tip. I have just tried out a version with all short jumps. It is 151 bytes long but curiously runs a little slower than the original. I am using an Athlon 3200. It must be feeling tired this evening because the performance of the original code is now 18,492 words/millisec instead of 19. With the short jumps this falls to 17,687. As you suggest, a lookup table approach, to minimise branching, will be well worth trying. I'll have a go tomorrow. ------------------ Charles IP: Logged
Paul Dixon Member	posted August 04, 2006 08:20 PM Charles, it's not curious. CPUs are very sensitive to things like code alignment. Even though the code is shorter it may not be as well aligned so it could run more slowly. In particular, when you jump to a label the alignment of that label makes a big difference and you have so many labels and jumps that it's not straight forward to align them all. Paul. ------------------ IP: Logged
Robert DeBolt Member	posted August 04, 2006 10:42 PM words/millisec 15700 Length of code: 251 AMD Athlon(tm) XP 2500+ 1.84 GHz. 512 MB of RAM Win XP/HE sp 2 ------------------ Regards, Bob -------- Composed with EZ-Post! IP: Logged

This topic is 4 pages long: 1 2 3 4 All times are EasternTime (US)	next newest topic \| next oldest topic
Administrative Options: Close Topic \| Archive/Move \| Delete Topic
	Hop to:

Contact Us | PowerBASIC BASIC Compilers

Copyright � 1999-2006 PowerBASIC, Inc. All Rights Reserved.

Ultimate Bulletin Board 5.45c