[Shootout-list] Directions of various benchmarks
José Bollo
jose.bollo@tele2.fr
Wed, 18 May 2005 16:03:05 +0200
Le mercredi 18 Mai 2005 12:52, skaller a écrit :
> On Wed, 2005-05-18 at 16:13, José Bollo wrote:
> > Le mercredi 18 Mai 2005 07:53, Bengt Kleberg a écrit :
> > > skaller wrote:
> > > ...deleted
> > >
> > > > Are we measuring the cost of interfacing to an
> > > > external library .. and if so how can we do that
> > > > when external libraries are excluded ..? <g>
> > >
> > > would it be a good idea to have a specific test for this purpouse?
> > > a ''foreign function interface'' test.
> > > and disallow such use in other tests?
> >
> > EIFFEL will win for interfacing any C / C++ / JAVA external libraries.
>
> Then it will be equal to Felix on simple tests -- and I curious what the
> interface looks like, can you show me?
really i regret what i wrote!
eiffel will not win!
eiffel is as so good as many languages are.
i will show you.
>
> > And forget such kind of test for many languages like Tcl / Java ...
> >
> > Let show an example:
> >
> > one write a C library and publish the interface:
> > float compute_it_fast(float x, float y)
>
> Felix, assuming the C code is included:
>
> fun compute_it_fast: float * float -> float;
in eiffel:
compute_it_fast(x,y: REAL_32): REAL_32 is external "C" end
>
> if the header lives in file 'fast.h' then:
>
> fun compute_it_fast : float * float -> float
> requires header '#include "fast.h"'
> ;
in eiffel:
compute_it_fast(x,y: REAL_32): REAL_32 is external "C using 'fast.h'" end
>
> which has the advantage of only including 'fast.h' if the
> function compute_it_fast is actually used. This leaves the problem
> of linking the code however this does not:
>
> fun compute_it_fast: float * float -> float
> requires body """
> float compute_it_fast (double x, double y) {
> return x + y;
> }
> """
> ;
great but not an external library call ;^)
in eiffel:
compute_it_fast(x,y: REAL_32): REAL_32 is
external "C inline" alias "return $x + $y" end
>
> which will compile the C from source along with the Felix that
> uses it (if, and only if, it is actually used .. ) and is therefore
> a complete 'single file' solution.
>
> Show me the Eiffel?
done. no?
>
> Now show me the Eiffel where the argument is a struct:
>
> struct C F2 { float x; float y; }
>
> Here is the Felix:
>
> cstruct F2 { x: float; y: float; }
> fun compute_it_fast: F2 -> float;
here are come troubles!!! but for that small example a tiny version would be:
in eiffel:
expanded class XY feature
x,y: REAL_32
put(a,b: like x) is do x:=a y:=b end
end
then:
compute_it_fast(xy: XY): REAL_32 is external "C" end
but the use of external structures has specific behaviour that will use
pointer as in (from memory, maybe a little variant in truth):
class XY feature
make(q: POINTER) is do p:=q end
x: REAL_32 is do Result := internal_get_x(p) end
set_x(v: REAL_32) is do internal_set_x(p,v) end
y: REAL_32 is do Result := internal_get_y(p) end
set_y(v: REAL_32) is do internal_set_y(p,v) end
feature {NONE}
internal_get_x(q: POINTER): REAL_32 is external "C struct name get x" end
internal_get_y(q: POINTER): REAL_32 is external "C struct name get y" end
internal_set_x(q: POINTER; v: REAL_32) is external "C struct name get x" end
internal_set_y(q: POINTER; v: REAL_32) is external "C struct name get y" end
p: POINTER
end
>
> [again with the option of making the inclusion of the header
> file conditional on actually using the type and/or function]
>
> So I'm claiming 1 LOC for problem 1, and 2 LOC for problem 2
> and NO language that can't read C headers can possibly beat that.
smarteiffel compiler generate C files that are compiled using a C compiler.
the header are usable that way.
but the compiler also can produce Java Byte codes and then the external are
related to the java language (external "JAVA" ...)
It exists of course a C++ binding
>
> The final challenge is much harder: a Gtk GUI function with
> a callback/client data argument .. Felix has a tool 'flxcc'
> that will detect this automatically and generate the required
> bindings including the conversion of a Felix closure object
> to a C function pointer/void *client_data pair .. but the actual
> interface code is quite messy and long winded (20 lines at least).
> At least some of it begs for a language extension to simplify it:)
exportations to C or Java of eiffel code is possible through CECIL mechanisms.
i have already used it to create an external library that C programs call.
the mix is possible.
>
> If Eiffel can do this more easily I'd love to see how .. does
> it escape by not having first class functions perhaps ..?
well i can give example of the cecil file i made.
-- output file name
cecil_svc.h
-- the features:
svc_make SVC_C_ITF make
svc_clear SVC_C_ITF clear
svc_start SVC_C_ITF start
svc_stop SVC_C_ITF stop
svc_add_entry SVC_C_ITF add_entry
svc_add_line SVC_C_ITF add_line
svc_add_substitution SVC_C_ITF add_substitution
svc_size SVC_C_ITF size
the name of the output for the C use
the exported C name, the class, the feature in the class
for the GTK binding please see
eGTK: http://www.netlabs.net/hp/richieb/gtk_eiffel.html
eGLADE: http://www.lfix.co.uk/eiflib/
>
> I would be dumbfouned if ANY language other than C, C++, or a language
> which is an extension of C or C++, will come even close to what
> Felix can do -- it supports not only interfacing to C and C++,
> it manages the dependency graph as well, to ensure only used C
> code is instantiated, provides conditional compilation,
> AND the instantiation is *polymorphic* on top of all that,
> in addition to functions and types (as above) procedures,
> values, inline expressions, inline statements, and floating
> header and body code are also supported, along with
> several 'shortcuts' (the example above are all special
> cases using shortcuts .. :)
FELIX seems good
>
> The high level of sophistication of the 'FFI' system
> isn't just for 'interfacing to C': almost all the primitives --
> and thus the language semantics -- are actually defined in
> the library using these tools. There is, for example,
> no integer type in Felix .. it has to be defined by the user:
>
> type int = "int";
>
> and you can just as easily define:
>
> type int = "long long int";
>
> or
>
> type int = "char";
>
> and more importantly, you can (I hope!!!!) define your basic
> types as Microsoft CLI .NET data types and *presto* Felix is
> a .NET language.
>
> Of course you can't add integers until you define:
>
> fun add: int * int -> int = "$1 + $2";
> // the name 'add' is special, and names the infix + operator too
>
> so for example the entire numerical system is defined by the user --
> usually by just including the standard library.
well SmartEiffel do it the same way except that it also can produce native
Java Bytecode
>
> It kinds of makes 'integer arithmetic performance testing' a joke:
> since the operations are all user defined bindings to C anyhow,
> it begs the question "which integers and operations are you
> talking about?"
I will surely be welcome on pluton the day i will stop there ;^)
>
> > then you must call that library
> > with JAVA: write an additional C library that is a JNI/C proxy stub
> > it is not JAVA
> > it is boring
> > it is not interesting
> > Same with Tcl and many other languages
> > C and C++ are naturally privileged
> > EIFFEL do it in one line
> >
> > And from an other point de vue, it is not interresting because CORBA
> > (ORBIT), client/server protocols, are better ways of integrating
> > libraries/components in an huge project.
>
> I agree 'it is boring' writing interfacing code, but it is essential
> sometimes and it is an important feature of a language. Ocaml claims
> a simple FFI, the Python one is hard, Tcl used to be easy but the newer
> versions have made it much harder (IMHO).
>
> I didn't know Eiffel could do this as easily as Felix, which was
> specifically designed to make it easy -- in other words it is
> something useful that might be learned from including such a test!
Thank you to give me the opportunity to show these features
josé