Index: doc/bibliography/pl.bib =================================================================== --- doc/bibliography/pl.bib (revision deb52a099a531df5b0f8d93d94f08c9597703efb) +++ doc/bibliography/pl.bib (revision 29db7239b8192d870e72ad96c020f2db4b40c2bc) @@ -6061,11 +6061,24 @@ } +@article{Nickolls08, + author = {Nickolls, John and Buck, Ian and Garland, Michael and Skadron, Kevin}, + title = {Scalable Parallel Programming with CUDA}, + journal = {Queue}, + volume = {6}, + number = {2}, + month = mar, + year = 2008, + pages = {40-53}, + publisher = {ACM}, + address = {New York, NY, USA}, +} + @inproceedings{Leissa14, - title={Sierra: a SIMD extension for C++}, - author={Lei{\ss}a, Roland and Haffner, Immanuel and Hack, Sebastian}, - booktitle={Proceedings of the 2014 Workshop on Workshop on programming models for SIMD/Vector processing}, - pages={17--24}, - year={2014}, - organization={ACM} + title = {Sierra: a SIMD extension for C++}, + author = {Lei{\ss}a, Roland and Haffner, Immanuel and Hack, Sebastian}, + booktitle = {Proceedings of the 2014 Workshop on Workshop on programming models for SIMD/Vector processing}, + pages = {17--24}, + year = {2014}, + organization= {ACM} } @@ -6310,5 +6323,5 @@ @article{Smith98, keywords = {Polymorphic C}, - contributor = {a3moss@uwaterloo.ca}, + contributor = {a3moss@uwaterloo.ca}, title = {A sound polymorphic type system for a dialect of C}, author = {Smith, Geoffrey and Volpano, Dennis}, Index: doc/papers/general/Paper.tex =================================================================== --- doc/papers/general/Paper.tex (revision deb52a099a531df5b0f8d93d94f08c9597703efb) +++ doc/papers/general/Paper.tex (revision 29db7239b8192d870e72ad96c020f2db4b40c2bc) @@ -146,6 +146,6 @@ % replace/adjust listing characters that look bad in sanserif literate={-}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.1ex}}}}1 {^}{\raisebox{0.6ex}{$\scriptscriptstyle\land\,$}}1 - {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 {@}{\small{@}}1 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1 - {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {->}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.075ex}}}\kern-0.2ex\textgreater}2, + {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 {@}{\small{@}}1 {<}{\small{\textless}}1 {>}{\small{\textgreater}}1 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1 + {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {->}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.075ex}}}\kern-0.2ex{\small\textgreater}}2, moredelim=**[is][\color{red}]{`}{`}, }% lstset @@ -436,5 +436,5 @@ One approach is to write bespoke data-structures for each context in which they are needed. While this approach is flexible and supports integration with the C type-checker and tooling, it is also tedious and error-prone, especially for more complex data structures. -A second approach is to use @void *@ based polymorphism, \eg the C standard-library functions @bsearch@ and @qsort@, which allow reuse of code with common functionality. +A second approach is to use @void *@-based polymorphism, \eg the C standard-library functions @bsearch@ and @qsort@, which allow reuse of code with common functionality. However, basing all polymorphism on @void *@ eliminates the type-checker's ability to ensure that argument types are properly matched, often requiring a number of extra function parameters, pointer indirection, and dynamic allocation that is not otherwise needed. A third approach to generic code is to use preprocessor macros, which does allow the generated code to be both generic and type-checked, but errors may be difficult to interpret. @@ -526,5 +526,5 @@ Results of these layout functions are cached so that they are only computed once per type per function. %, as in the example below for @pair@. Layout functions also allow generic types to be used in a function definition without reflecting them in the function signature. -For instance, a function that strips duplicate values from an unsorted @vector(T)@ would likely have a pointer to the vector as its only explicit parameter, but use some sort of @set(T)@ internally to test for duplicate values. +For instance, a function that strips duplicate values from an unsorted @vector(T)@ likely has a pointer to the vector as its only explicit parameter, but uses some sort of @set(T)@ internally to test for duplicate values. This function could acquire the layout for @set(T)@ by calling its layout function with the layout of @T@ implicitly passed into the function. @@ -796,5 +796,5 @@ Since @void@ is effectively a 0-element tuple, (3) discards the first and third return values, which is effectively equivalent to @[(int)(g().1.0), (int)(g().1.1)]@). -Note that a cast is not a function call in \CFA, so flattening and structuring conversions do not occur for cast expressions\footnote{User-defined conversions have been considered, but for compatibility with C and the existing use of casts as type ascription, any future design for such conversions would require more precise matching of types than allowed for function arguments and parameters.}. +Note that a cast is not a function call in \CFA, so flattening and structuring conversions do not occur for cast expressions\footnote{User-defined conversions have been considered, but for compatibility with C and the existing use of casts as type ascription, any future design for such conversions requires more precise matching of types than allowed for function arguments and parameters.}. As such, (4) is invalid because the cast target type contains 4 components, while the source type contains only 3. Similarly, (5) is invalid because the cast @([int, int, int])(g().1)@ is invalid. @@ -1159,5 +1159,5 @@ case 4: ... `fallthrough common;` - common: + common: // below fallthrough and at same level as case clauses ... // common code for cases 3 and 4 // implicit break @@ -1167,5 +1167,6 @@ \lstMakeShortInline@% \end{cquote} -The target label may be case @default@. +The target label must be below the @fallthrough@, \ie @fallthrough@ cannot form a loop, and the label may not be nested in a control structor, \ie it must be at the same level as the @case@ clauses; +the target label may be case @default@. Collectively, these control-structure enhancements reduce programmer burden and increase readability and safety. @@ -1447,5 +1448,5 @@ struct T { double m, n; }; int C::f( T & t ) { $\C{// multiple aggregate parameters}$ - c; i; d; $\C{\color{red}// this-\textgreater.c, this-\textgreater.i, this-\textgreater.d}$ + c; i; d; $\C{\color{red}// this--{\small\textgreater}.c, this--{\small\textgreater}.i, this--{\small\textgreater}.d}$ `t.`m; `t.`n; $\C{// must qualify}$ } @@ -1532,5 +1533,5 @@ S * sp = &sv; with ( *sp ) { $\C{computed reference}$ - i = 3; j = 4; $\C{\color{red}// sp-{\textgreater}i, sp-{\textgreater}j}$ + i = 3; j = 4; $\C{\color{red}// sp--{\small\textgreater}i, sp--{\small\textgreater}j}$ } i = 2; j = 3; $\C{\color{red}// sr.i, sr.j}$ @@ -2525,6 +2526,8 @@ The \CFA interface wraps GMP functions into operator functions to make programming with multi-precision integers identical to using fixed-sized integers. The \CFA type name for multi-precision signed-integers is @Int@ and the header file is @gmp@. -The following multi-precision factorial programs contrast using GMP with the \CFA and C interfaces. -\begin{cquote} +Figure~\ref{f:GMPInterface} shows a multi-precision factorial-program contrasting the GMP interface in \CFA and C. + +\begin{figure} +\centering \lstDeleteShortInline@% \begin{tabular}{@{}l@{\hspace{\parindentlnth}}@{\hspace{\parindentlnth}}l@{}} @@ -2557,5 +2560,7 @@ \end{tabular} \lstMakeShortInline@% -\end{cquote} +\caption{GMP Interface \CFA versus C} +\label{f:GMPInterface} +\end{figure} @@ -2566,8 +2571,8 @@ In fact, \CFA's features for generic programming can enable faster runtime execution than idiomatic @void *@-based C code. This claim is demonstrated through a set of generic-code-based micro-benchmarks in C, \CFA, and \CC (see stack implementations in Appendix~\ref{sec:BenchmarkStackImplementation}). -Since all these languages share a subset essentially comprising standard C, maximal-performance benchmarks would show little runtime variance, differing only in length and clarity of source code. -A more illustrative benchmark measures the costs of idiomatic usage of each language's features. +Since all these languages share a subset essentially comprising standard C, maximal-performance benchmarks should show little runtime variance, differing only in length and clarity of source code. +A more illustrative comparison measures the costs of idiomatic usage of each language's features. Figure~\ref{fig:BenchmarkTest} shows the \CFA benchmark tests for a generic stack based on a singly linked-list. -The benchmark test is similar for C and \CC. +The benchmark test is similar for the other languages. The experiment uses element types @int@ and @pair(short, char)@, and pushes $N=40M$ elements on a generic stack, copies the stack, clears one of the stacks, and finds the maximum value in the other stack. @@ -2621,5 +2626,5 @@ \begin{tabular}{rrrrr} & \CT{C} & \CT{\CFA} & \CT{\CC} & \CT{\CCV} \\ \hline -maximum memory usage (MB) & 10001 & 2502 & 2503 & 11253 \\ +maximum memory usage (MB) & 10,001 & 2,502 & 2,503 & 11,253 \\ source code size (lines) & 187 & 186 & 133 & 303 \\ redundant type annotations (lines) & 25 & 0 & 2 & 16 \\ @@ -2645,10 +2650,12 @@ Raw line-count, however, is a fairly rough measure of code complexity; another important factor is how much type information the programmer must manually specify, especially where that information is not checked by the compiler. -Such unchecked type information produces a heavier documentation burden and increased potential for runtime bugs, and is much less common in \CFA than C, with its manually specified function pointer arguments and format codes, or \CCV, with its extensive use of un-type-checked downcasts (\eg @object@ to @integer@ when popping a stack, or @object@ to @printable@ when printing the elements of a @pair@). -To quantify this, the ``redundant type annotations'' line in Table~\ref{tab:eval} counts the number of lines on which the type of a known variable is re-specified, either as a format specifier, explicit downcast, type-specific function, or by name in a @sizeof@, struct literal, or @new@ expression. +Such unchecked type information produces a heavier documentation burden and increased potential for runtime bugs, and is much less common in \CFA than C, with its manually specified function pointer arguments and format codes, or \CCV, with its extensive use of untype-checked downcasts, \eg @object@ to @integer@ when popping a stack. +To quantify this manual typing, the ``redundant type annotations'' line in Table~\ref{tab:eval} counts the number of lines on which the type of a known variable is respecified, either as a format specifier, explicit downcast, type-specific function, or by name in a @sizeof@, struct literal, or @new@ expression. The \CC benchmark uses two redundant type annotations to create a new stack nodes, while the C and \CCV benchmarks have several such annotations spread throughout their code. -The \CFA benchmark was able to eliminate all redundant type annotations through use of the polymorphic @alloc@ function discussed in Section~\ref{sec:libraries}. +The \CFA benchmark is able to eliminate all redundant type annotations through use of the polymorphic @alloc@ function discussed in Section~\ref{sec:libraries}. + \section{Related Work} + \subsection{Polymorphism} @@ -2708,34 +2715,42 @@ Tuples are a fundamental abstraction in most functional programming languages, such as Standard ML~\cite{sml} and~\cite{Scala}, which decompose tuples using pattern matching. + \subsection{C Extensions} -\CC is the best known C-based language, and similar to \CFA in that both are extensions to C with source and runtime backwards compatibility. -\CC and \CFA have been extensively compared in this paper, but the key difference between their design philosophies is that \CFA aims to be easy for C programmers to understand, by maintaining a procedural paradigm and avoiding complex interactions between extension features. +\CC is the best known C-based language, and is similar to \CFA in that both are extensions to C with source and runtime backwards compatibility. +Specific difference between \CFA and \CC have been identified in prior sections, with a final observation that \CFA has equal or few tokens to express the same notion in several cases. +The key difference between design philosophies is that \CFA is easier for C programmers to understand, by maintaining a procedural paradigm and avoiding complex interactions among extensions. \CC, on the other hand, has multiple overlapping features (such as the three forms of polymorphism), many of which have complex interactions with its object-oriented design. -As such, though \CC provides good runtime performance and compatibility with C, it has a steep learning curve for even experienced C programmers. - -There are many other C extension languages with less usage and dramatic changes than \CC. +As a result, \CC has a steep learning curve for even experienced C programmers, especially when attempting to maintain performance equivalent to C legacy code. + +There are several other C extension-languages with less usage and even more dramatic changes than \CC. Objective-C and Cyclone are two other extensions to C with different design goals than \CFA, as discussed above. -Many other languages extend C with more focused single features. -CUDA\cite{CUDA}, ispc\cite{Pharr12}, and Sierra\cite{Leissa14} add data-parallel primitives to C or \CC; such features have not yet been added to \CFA, but are not precluded by the design. -Other C extensions attempt to provide a more memory-safe C;\TODO{find some} type-checked polymorphism in \CFA covers many of C's memory-safety holes, but more aggressive approaches such as annotating all pointer types with their nullability are contradictory to \CFA's backwards compatibility goals. - -% \subsection{Control Structures / Declarations / Literals} - -% Java has default fall through like C/\CC. -% Pascal/Ada/Go/Rust do not have default fall through. -% \Csharp does not have fall through but still requires a break. -% Python uses dictionary mapping. \\ -% \CFA choose is like Rust match. - -% Java has labelled break/continue. \\ -% Languages with and without exception handling. - -% Alternative C declarations. \\ -% Different references \\ -% Constructors/destructors - -% 0/1 Literals \\ -% user defined: D, Objective-C +Other languages extend C with more focused features. +CUDA~\cite{Nickolls08}, ispc~\cite{Pharr12}, and Sierra~\cite{Leissa14} add data-parallel primitives to C or \CC; +such features have not yet been added to \CFA, but are not precluded by the design. +Finaly, some C extensions (or suggested extensions) attempt to provide a more memory-safe C~\cite{Boehm88}; +type-checked polymorphism in \CFA covers several of C's memory-safety holes, but more aggressive approaches such as annotating all pointer types with their nullability are contradictory to \CFA's backwards compatibility goals. + + +\begin{comment} +\subsection{Control Structures / Declarations / Literals} + +Java has default fall through like C/\CC. +Pascal/Ada/Go/Rust do not have default fall through. +\Csharp does not have fall through but still requires a break. +Python uses dictionary mapping. \\ +\CFA choose is like Rust match. + +Java has labelled break/continue. \\ +Languages with and without exception handling. + +Alternative C declarations. \\ +Different references \\ +Constructors/destructors + +0/1 Literals \\ +user defined: D, Objective-C +\end{comment} + \section{Conclusion and Future Work} @@ -2784,4 +2799,46 @@ \smallskip\noindent +C +\begin{cfa}[xleftmargin=2\parindentlnth,aboveskip=0pt,belowskip=0pt] +struct stack_node { + void * value; + struct stack_node * next; +}; +struct stack { struct stack_node* head; }; +struct stack new_stack() { return (struct stack){ NULL }; /***/ } +void copy_stack( struct stack * s, const struct stack * t, void * (*copy)( const void * ) ) { + struct stack_node ** crnt = &s->head; + for ( struct stack_node * next = t->head; next; next = next->next ) { + *crnt = malloc( sizeof(struct stack_node) ); /***/ + (*crnt)->value = copy( next->value ); + crnt = &(*crnt)->next; + } + *crnt = NULL; +} +_Bool stack_empty( const struct stack * s ) { return s->head == NULL; } +void push_stack( struct stack * s, void * value ) { + struct stack_node * n = malloc( sizeof(struct stack_node) ); /***/ + *n = (struct stack_node){ value, s->head }; /***/ + s->head = n; +} +void * pop_stack( struct stack * s ) { + struct stack_node * n = s->head; + s->head = n->next; + void * x = n->value; + free( n ); + return x; +} +void clear_stack( struct stack * s, void (*free_el)( void * ) ) { + for ( struct stack_node * next = s->head; next; ) { + struct stack_node * crnt = next; + next = crnt->next; + free_el( crnt->value ); + free( crnt ); + } + s->head = NULL; +} +\end{cfa} + +\medskip\noindent \CFA \begin{cfa}[xleftmargin=2\parindentlnth,aboveskip=0pt,belowskip=0pt] @@ -2817,8 +2874,8 @@ stack_node(T) * n = head; head = n->next; - T x = n->value; + T v = n->value; ^(*n){}; free( n ); - return x; + return v; } forall( otype T ) void clear( stack(T) & s ) with( s ) { @@ -2840,8 +2897,8 @@ T value; node * next; - node( const T & v, node * n = nullptr ) : value(v), next(n) {} + node( const T & v, node * n = nullptr ) : value( v), next( n) {} }; node * head; - void copy(const stack & o) { + void copy( const stack & o) { node ** crnt = &head; for ( node * next = o.head;; next; next = next->next ) { @@ -2851,15 +2908,15 @@ *crnt = nullptr; } - stack() : head(nullptr) {} - stack(const stack & o) { copy(o); } - stack(stack && o) : head(o.head) { o.head = nullptr; } + stack() : head( nullptr) {} + stack( const stack & o) { copy( o); } + stack( stack && o) : head( o.head) { o.head = nullptr; } ~stack() { clear(); } - stack & operator= (const stack & o) { + stack & operator= ( const stack & o) { if ( this == &o ) return *this; clear(); - copy(o); + copy( o); return *this; } - stack & operator= (stack && o) { + stack & operator= ( stack && o) { if ( this == &o ) return *this; head = o.head; @@ -2868,9 +2925,9 @@ } bool empty() const { return head == nullptr; } - void push(const T & value) { head = new node{ value, head }; /***/ } + void push( const T & value) { head = new node{ value, head }; /***/ } T pop() { node * n = head; head = n->next; - T x = std::move(n->value); + T x = std::move( n->value); delete n; return x; @@ -2888,46 +2945,4 @@ \medskip\noindent -C -\begin{cfa}[xleftmargin=2\parindentlnth,aboveskip=0pt,belowskip=0pt] -struct stack_node { - void * value; - struct stack_node * next; -}; -struct stack { struct stack_node* head; }; -struct stack new_stack() { return (struct stack){ NULL }; /***/ } -void copy_stack(struct stack * s, const struct stack * t, void * (*copy)(const void *)) { - struct stack_node ** crnt = &s->head; - for ( struct stack_node * next = t->head; next; next = next->next ) { - *crnt = malloc(sizeof(struct stack_node)); /***/ - (*crnt)->value = copy(next->value); - crnt = &(*crnt)->next; - } - *crnt = NULL; -} -_Bool stack_empty(const struct stack * s) { return s->head == NULL; } -void push_stack(struct stack * s, void * value) { - struct stack_node * n = malloc(sizeof(struct stack_node)); /***/ - *n = (struct stack_node){ value, s->head }; /***/ - s->head = n; -} -void * pop_stack(struct stack * s) { - struct stack_node * n = s->head; - s->head = n->next; - void * x = n->value; - free(n); - return x; -} -void clear_stack(struct stack * s, void (*free_el)(void *)) { - for ( struct stack_node * next = s->head; next; ) { - struct stack_node * crnt = next; - next = crnt->next; - free_el(crnt->value); - free(crnt); - } - s->head = NULL; -} -\end{cfa} - -\medskip\noindent \CCV \begin{cfa}[xleftmargin=2\parindentlnth,aboveskip=0pt,belowskip=0pt] @@ -2939,5 +2954,5 @@ }; node* head; - void copy(const stack & o) { + void copy( const stack & o ) { node ** crnt = &head; for ( node * next = o.head; next; next = next->next ) { @@ -2947,15 +2962,15 @@ *crnt = nullptr; } - stack() : head(nullptr) {} - stack(const stack & o) { copy(o); } - stack(stack && o) : head(o.head) { o.head = nullptr; } + stack() : head( nullptr ) {} + stack( const stack & o ) { copy( o ); } + stack( stack && o ) : head( o.head ) { o.head = nullptr; } ~stack() { clear(); } - stack & operator= (const stack & o) { + stack & operator= ( const stack & o ) { if ( this == &o ) return *this; clear(); - copy(o); + copy( o ); return *this; } - stack & operator= (stack && o) { + stack & operator= ( stack && o ) { if ( this == &o ) return *this; head = o.head; @@ -2964,9 +2979,9 @@ } bool empty() const { return head == nullptr; } - void push(const object & value) { head = new node{ value, head }; /***/ } + void push( const object & value ) { head = new node{ value, head }; /***/ } ptr pop() { node * n = head; head = n->next; - ptr x = std::move(n->value); + ptr x = std::move( n->value ); delete n; return x; Index: doc/papers/general/evaluation/cfa-stack.c =================================================================== --- doc/papers/general/evaluation/cfa-stack.c (revision deb52a099a531df5b0f8d93d94f08c9597703efb) +++ doc/papers/general/evaluation/cfa-stack.c (revision 29db7239b8192d870e72ad96c020f2db4b40c2bc) @@ -2,12 +2,12 @@ #include "cfa-stack.h" -forall(otype T) struct stack_node { +forall( otype T ) struct stack_node { T value; stack_node(T) * next; }; -forall(otype T) void ?{}( stack(T) & s ) { (s.head){ 0 }; } +forall( otype T ) void ?{}( stack(T) & s ) { (s.head){ 0 }; } -forall(otype T) void ?{}( stack(T) & s, stack(T) t ) { +forall( otype T ) void ?{}( stack(T) & s, stack(T) t ) { stack_node(T) ** crnt = &s.head; for ( stack_node(T) * next = t.head; next; next = next->next ) { @@ -19,5 +19,5 @@ } -forall(otype T) stack(T) ?=?( stack(T) & s, stack(T) t ) { +forall( otype T ) stack(T) ?=?( stack(T) & s, stack(T) t ) { if ( s.head == t.head ) return s; clear( s ); @@ -26,24 +26,24 @@ } -forall(otype T) void ^?{}( stack(T) & s) { clear( s ); } +forall( otype T ) void ^?{}( stack(T) & s) { clear( s ); } -forall(otype T) _Bool empty( const stack(T) & s ) { return s.head == 0; } +forall( otype T ) _Bool empty( const stack(T) & s ) { return s.head == 0; } -forall(otype T) void push( stack(T) & s, T value ) with( s ) { - stack_node(T)* n = alloc(); +forall( otype T ) void push( stack(T) & s, T value ) with( s ) { + stack_node(T) * n = alloc(); (*n){ value, head }; head = n; } -forall(otype T) T pop( stack(T) & s ) with( s ) { +forall( otype T ) T pop( stack(T) & s ) with( s ) { stack_node(T) * n = head; head = n->next; - T x = n->value; + T v = n->value; ^(*n){}; free( n ); - return x; + return v; } -forall(otype T) void clear( stack(T) & s ) with( s ) { +forall( otype T ) void clear( stack(T) & s ) with( s ) { for ( stack_node(T) * next = head; next; ) { stack_node(T) * crnt = next; Index: doc/papers/general/evaluation/cfa-stack.h =================================================================== --- doc/papers/general/evaluation/cfa-stack.h (revision deb52a099a531df5b0f8d93d94f08c9597703efb) +++ doc/papers/general/evaluation/cfa-stack.h (revision 29db7239b8192d870e72ad96c020f2db4b40c2bc) @@ -1,16 +1,16 @@ #pragma once -forall(otype T) struct stack_node; -forall(otype T) struct stack { +forall( otype T ) struct stack_node; +forall( otype T ) struct stack { stack_node(T) * head; }; -forall(otype T) void ?{}( stack(T) & s ); -forall(otype T) void ?{}( stack(T) & s, stack(T) t ); -forall(otype T) stack(T) ?=?( stack(T) & s, stack(T) t ); -forall(otype T) void ^?{}( stack(T) & s); +forall( otype T ) void ?{}( stack(T) & s ); +forall( otype T ) void ?{}( stack(T) & s, stack(T) t ); +forall( otype T ) stack(T) ?=?( stack(T) & s, stack(T) t ); +forall( otype T ) void ^?{}( stack(T) & s); -forall(otype T) _Bool empty( const stack(T) & s ); -forall(otype T) void push( stack(T) & s, T value ); -forall(otype T) T pop( stack(T) & s ); -forall(otype T) void clear( stack(T) & s ); +forall( otype T ) _Bool empty( const stack(T) & s ); +forall( otype T ) void push( stack(T) & s, T value ); +forall( otype T ) T pop( stack(T) & s ); +forall( otype T ) void clear( stack(T) & s ); Index: doc/papers/general/evaluation/timing.gp =================================================================== --- doc/papers/general/evaluation/timing.gp (revision deb52a099a531df5b0f8d93d94f08c9597703efb) +++ doc/papers/general/evaluation/timing.gp (revision 29db7239b8192d870e72ad96c020f2db4b40c2bc) @@ -22,4 +22,7 @@ SCALE=1000 set ylabel "seconds" +set yrange [0:10] + +set label "26.5" at 7.125,10.5 # set datafile separator ","