hardcoding finite automata

1

HARDCODING FINITE HARDCODING FINITE AUTOMATAAUTOMATA

Ernest Ketcha Ngassam

Prof. Bruce W. Watson

Prof. Derrick G. Kourie

Department of Computer Science

University of Pretoria

Fastar Research Group

http://fastar.cs.up.ac.za

2

Introductory RemarksIntroductory Remarks• FA Definition: (Σ, S, F, δ, s0)

– Finite set of Alphabet symbols (Σ)– Finite set of states (S)– Finite set of accepting states (F)– Transition function (δ)– Starting state (s0)

• FAs Context– Chomsky hierarchy– Right linear grammar

• Many FAs Applications– Pattern matching in text– Text indexing– Computational genetics– Network intrusion detection– Computer and natural virus scanning– Natural language translation– Spell checking– Etc.

• FAs are therefore performance-sensitive

CFL CSLRLL

UL

CFL CSLRLL

UL

3

Related workRelated work• 1986, Penello in “Very fast LR Parsing”

– System that produces hardcoded parsers in Assembly Language

• 1988, Horspool and Whitney in “Even Faster LR Parsing”– Used Pennello’s idea

– Additional optimization strategies to reduce the code size

– Some fine tuning

• 1995, Bhamidipaty and Proebsting in “Very fast YACC-Compatible Parsers (For Very Little Effort)”

– YACC produces table-driven Parsers

– The method produced directly executable hardcoded parsers in C

• 2002, Kimmel in “Programming with Regular Expressions in C#”

– Suggests implementation of regular expressions in Assembler

4

Conventional FA Conventional FA ImplementationImplementation

• Objective: Determine if a string is in a language represented by an FA?

• Key issue: – Transition table that embeds

» Alphabet

» States

» Entries– Uses function / ”controller” recognize(str, transition): boolean

» Checks for acceptance symbol per symbol from str

» Transverses the table transition

» Returns true or false

Ch1 Ch2 Ch3 Ch4 Ch5 Ch6 Ch7 Ch8

1

2

3

4

(i,chk)

5

What is a Hardcoded What is a Hardcoded algorithm?algorithm?

• No table as data structure

• Only Primitive data types used

• Data embedded into algorithm – Data are part of the instructions

• Uses function recognize(str): boolean– Checks for acceptance symbol per symbol from str

– Returns true or false

read(str[0]);

goto label_0;

label_0:

action_0;

read(str[1]);

goto label_1;

label_1:

action_1;

read(str[2]);

goto label_2;

…

…

label_{n-1}:

action_{n-1};

goto decision;

…

Inst ru

ct ion

s

6

• Table-driven heavily depends on data

• Hardcoded heavily depends on instructions

• Computationally equivalents O(len)

• Need to perform empirical evaluation!

Table-driven vs. Hardcoded Table-driven vs. Hardcoded AlgorithmsAlgorithms

External Data

Control program

Table-driven Hardcoded

External Data

Instructions / Machine codes

7

Preliminary ExperimentsPreliminary Experiments• Based on single symbol recognition

– Easy to implement

» Problem domain restricted

– Various implementation strategies for the hardcoded algorithm

» High-level language (2 variations)

» Low-level language (3 variations)

– Baseline for string recognition

• Table-driven Algorithm reflects work for any transition function

• Hardcoded Algorithm reflects work for specific transition function

a b c d e

8 -1 -1 2 0

Transition array

s0

e

d

a

8

The Experiment & Data CollectionThe Experiment & Data Collection

1. Generate random transition array

2. Measure clock cycles using1. The control program for Table-driven (C++)

2. Hardcoded program (5 variations)

» Switch statement (C++)

» Nested conditionals (C++)

» Linear search (ASM)

» Jump table (ASM)

» Direct jump (ASM)

9

Preliminary ResultsPreliminary Results• Just an indication on how to continue with experiments

• Hardcode outperforms table-driven (in low-level language)

• Conclusion:– Rely on jump table version for further experiments

– Use it to explore cache effects

10

88.21 93.56

3.979.22 12.03

0

10

20

30

40

50

60

70

80

90

100

Av

era

ge

tim

e in

clo

ck c

ycl

es

Table-driven

High level switch statements

High level conditional statements

Low level jump table

Low level l inear search

Low level direct jump

Implementation techniques

10

A Simple String Test A Simple String Test ExperimentExperiment

• Language based on:1. Accepting symbol (a)

2. Rejecting symbol (b)

• In each of the n-1 states» a : triggers a transition to the next state

» b : does not trigger transition

• Only string accepted: aaa…aaa (n-1 times)– Represents worst case scenario

– Not concerned about reducing the FA

• Use Jump table and table-driven versions

1 2 3 na a a a

11

Performance based on 2 symbols Performance based on 2 symbols alphabetalphabet

0

10

20

30

40

50

60

70

80

10 1010 2010 3010

Number of states

Ave

rag

e o

f m

inim

um

tim

e /

stat

e in

ccs

Hardcode (single state)Table-driven (single state)

Hardcode (2 symbols alphabet)

Table-driven (2 symbols alphabet)

• Remark:

• Caching effect on the hardcoded version

• L1 cache (Hits) between 10 states and about 110 states

• L1 cache (Misses) between 160 states and about 360 states

• L2 cache (Hits) between 460 states and 1700 states

• Slow L2 cache (Misses) from 1800 states then need Main memory

12

The String Recognition The String Recognition ExperimentExperiment

str1 str2 str3 str4 str5

String1 2 3 n

13


• Two ways of Implementing a string recognizer:

String


1 2 3 n

14


• Two ways of Implementing a string recognizer:– Implementation based on direct indexing


ch1 ch2 ch3 ch4 ch5

1

2

3

4

(i,val(strk))String

1 2 3 n

15



– Implementation based on symbol searching

a( 1) b(2) c( 3) d(4) e( 5)

1

2

3

4


String

edcba

Array of alphabet symbols

(i, pos(strk))

1 2 3 n

16



– Implementation based on symbol searching

» Binary search

» Linear search• We used Linear search


a( 1) b(2) c( 3) d(4) e( 5)

1

2

3

4

String

edcba

Array of alphabet symbols

(i, pos(strk))

1 2 3 n

17


• Language based on:– 10-symbol alphabet

• Number of states between 10 and 4000

• Randomly generate accepting string of length n-1 (n automaton size)

• Filling density of each automaton sets to 41%

1 2 3 n

18

0.0

50.0

100.0

150.0

200.0

250.0

300.0

350.0

400.0

10 1010 2010 3010

Number of states

Ave

rag

e o

f m

inim

um

tim

e /

stat

e in

ccs

Table-driven direct index

Hardcode direct index

Hardcode searching

Table-driven searching

The String Recognition ExperimentThe String Recognition Experiment

• Remarks and Finding:

• Caching effect on the hardcoded version

• Noises due to Branch Prediction Buffer

• Wrong guesses in the Branch History Buffer

• Hardcoding outperforms table-driven up to a thousand states

19

Future WorkFuture Work

• Dynamic Implementation of Finite Automata for Performance (DIFAP) using:

– Table-driven– Linked list– Hardcode– Fine tuning,– Constraints,– Etc.

• An Adaptive method for DIFAP (A-DIFAP)– Adapts to system’s/platform’s constraints at run-time

• Programming Language specific toolkit for DIFAP / A-DIFAP– Exploits programming language’s features

20

PublicationsPublications

• Preliminary Experiments on Hardcoding Finite Automata. CIAA 2003

• Hardcoding Finite State Automata Processing. SAICSIT 2003

• Hardcoding Finite State Automata Processing. (Submitted to SACJ)

• On Hardcoding Finite State Automata Processing. Technical Report T/UE 2003.

• The Effect of Cache Memory on Hardcoded Finite Automata (To be submitted to SP&E)

21

Thanks! Thanks!

Questions?

hardcoding finite automata

Documents