<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//en">

<!–Converted with LaTeX2HTML 2022 (Released January 1, 2022) –> <HTML lang="en"> <HEAD> <TITLE>Contents of Performance of C-ified code</TITLE>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8"> <META NAME="viewport" CONTENT="width=device-width, initial-scale=1.0"> <META NAME="Generator" CONTENT="LaTeX2HTML v2022">

<LINK REL="STYLESHEET" HREF="art_tex.css">

<LINK REL="previous" HREF="node16_mn.html"> <LINK REL="up" HREF="node16_mn.html"> <LINK REL="next" HREF="node18_mn.html"> </HEAD>

<BODY bgcolor="#ffffff" text="#000000" link="#9944EE" vlink="#0000ff" alink="#00ff00">

<H2><A ID="SECTION00071000000000000000"> Performance of C-ified code</A> </H2>

<P> The speed-up clearly depends on the amount of C-ification and on the statistical importance of C-ified code in the execution profile of a program (see figure&nbsp;<A HREF="node17_ct.html#bm"><IMG ALT="[*]" SRC="crossref.png"></A>). We have noticed between 10-20programs which take advantage of C-ified code moderately, As these programs spend only 20-30in C-ified sequences performances are expected to scale correspondingly when we extend this approach to the full BinProlog instruction set and implement low-level gcc direct jumps instead of function calls and anti-calls.

<P>

<DIV class="CENTER"><A ID="bm"></A><A ID="447"></A> <TABLE> <CAPTION class="BOTTOM"><STRONG>Figure:</STRONG> Performance of emulated (emBP) and partially C-ified BinProlog 3.22 (C-BP) compared to emulated (emSP) and native (natSP) SICStus 2.1_9 on a Sparc 10/20). </CAPTION> <TR><TD><IMG STYLE="height: 286.76ex; " SRC="img1.png" ALT="

\begin{figure}\begin{center}
\begin{tabular}{\vert\vert l\vert\vert r\vert r\ver...
.....070 \\ \hline
\hline
\hline
\end{tabular} \\
\medskip\end{center}\end{figure}
"></TD></TR> </TABLE> </DIV>

<P> Code-sizes for C-ified BinProlog executables (dynamically linked on Sparcs with Solaris 2.3) are usually even smaller than `compact' Sicstus code which uses classical instruction folding (a few hundreds of opcodes) to speed-up the emulator.

<P> The following table shows some code-size/execution-speed variations with respect to the threshold for the semi-ring (<TT>SEMI3</TT>) benchmark. Clearly, excessively small chunks can influence adversely not only on size but also on speed. Something like threshold=20, looks like a practical optimum for this program.

<P> <PRE> threshold: 0 4 8 20 30 1000 emBP emSP natSP size: (K) 34.5 32.2 29.9 16.3 13.1 12.9 4.8 22.0 31.9 speed: (ms) 1480 1430 1440 1450 1810 1790 1800 1810 1310 </PRE>

<P>

<HR>

</BODY> </HTML>