Dear Sir. Thank you for your prompt answer.
Just for curiosity, and to see if I am in the right track, how does GNU Prolog behave? Are the figures you obtain as bad as Ciao Prolog's?
You are right. GnuProlog is almost as slow as Ciao Prolog.
After all, they are different languages, with Mercury requiring more user effort, such as modes, types, determinism declarations, etc., which makes translation to C (or assembler) easier.
Again, I am sure you are right. I think that mode and type inference makes Mercury run faster. I never declare modes or types. I always compile with the option "mmc --infer-all myprogram.m". In any case, Mercury infer modes and types. As for determinism, my students and I avoid non-deterministic predicates very carefully. Thus, I am sure that all predicates are deterministic.
Question: Is it possible to insert mode declaration in a Ciao-Prolog code? If the answer is yes, I could check how it influences speed.
I have made an experience with GNU-Prolog that may help. Dr. Marcus Vinicius, from Ryerson University (http://www.scs.ryerson.ca/~m3santos/) wrote a Prolog to C translator as part of his MSC thesis. I got a copy of this thesis and of the translator. A few years later, Dr. Cedric Carvalho wrote a Prolog to JVM compiler with mode and type inference. One of my students combined the two compilers to generate C code (instead of JVM) for GNU-Prolog. Then, I used gplc to compile and link this code to a GNU-Prolog program. With this off-hand scheme, I was able to compile only very simple programs. However, they proved to be as fast as equivalent programs in Mercury. Is it possible to add an option to Ciao Prolog to generate mode and type inference? Of course, it is possible. I think I should rephrase the question. Do you have plans to add mode and type inference to Ciao-Prolog?
Yes, it is true that we are working on compilation to C. However the compiler is still on a very preliminary stage, and although results are good, it is still far from being usable.
Would you accept volunteers? I am sending copies of this letter to Dr. Cedric and Dr. Marcus. They know well the kind of programs I write, and they may make suggestions. I am also sure that they would be happy to work as volunteers in your Prolog to C compiler, if you accept volunteers, of course.
By the way, I do not want to keep with Mercury because it generates ridiculously large code (ten times larger than Ciao Prolog, or GNU-Prolog). Finally, I am giving up Visual Prolog because it requires type declaration.
Eduardo Costa ============================================================================== Message: Address: Action: help majordomo(a)clip.dia.fi.upm.es Info. on useful commands subscribe ciao-users-request(a)clip.dia.fi.upm.es Subscribe to this list unsubscribe ciao-users-request(a)clip.dia.fi.upm.es Unsubscribe from this list <whatever> ciao-users(a)clip.dia.fi.upm.es Send message to list ----------------------------------------------------------------------------- Archived messages: http://www.clip.dia.fi.upm.es/Mail/ciao-users/ -----------------------------------------------------------------------------
Question: Is it possible to insert mode declarations in Ciao-Prolog code?
Definitely! Look up part five of the manual:
* *** PART V - Annotated Prolog library (assertions):: * The Ciao assertion package:: * Types and properties related to assertions:: * Declaring regular types:: * Properties which are native to analyzers:: * Meta-properties:: * ISO-Prolog modes:: * Classical Prolog modes:: * Run-time checking of assertions::
One of the nicest characteristics of Ciao is that it allows declaring types, modes, and many other properties of programs (even user-defined properties) using a very powerful assertion language. To use this language you need to load the 'assertions' package and, if you want to use types, the 'regtypes' package (some examples are included in the manual). We strongly believe that an assertion language like this should be part of any modern logic programming language.
If the answer is yes, I could check how it influences speed.
Unfortunately, the low-level compiler in the distribution does not do much with many of these assertions. It does use them for example in higher-order programming, in the database interface, for generating glue code in the C interface, etc., but not for optimization. On the other hand, 'lpdoc' (the autodocumenter, which is distributed with Ciao) understands the full assertion language and uses any assertions present in programs to automatically generate reference manuals. Typically, it pays off to put assertions for the exported predicates of a module even if were only for documentation purposes.
By the way, I do not want to keep with Mercury because it generates ridiculously large code (ten times larger than Ciao Prolog, or GNU-Prolog). Finally, I am giving up Visual Prolog because it requires type declaration.
Visual Prolog stems from Turbo Prolog, and belongs to a school of thought that developed early in logic programming where the philosophy was to *require* mode and type declarations (and impose restrictions in the language and pay in larger code size and compilation times) in exchange for more speed (Mercury also includes enhancements related to purity and declarativeness).
In Ciao (and in its predecessor, &-Prolog) we have always proposed an alternative model:
- The language should not be restricted.
- Declarations of program properties (modes, types, and others) should be voluntary, not compulsory. This allows programming 'in the large' (with modules with documented interfaces) and at the same programming in the small (small applications, scripts, prototyping, etc.).
- Speed (and error checking!) should be achieved by performing *inference* of modes, types (and many other properties).
- The user should be able to choose between traditional bytecode compilation (which has the advantage of reasonable speed and reasonable code size) or different degrees of optimized compilation (exchanging code size and compilation time --possibly including the time to infer types, modes and other properties-- for speed).
Our confidence from the very start in this model stemmed from our experience developing practical algorithms and tools for inference of modes, types, and many other properties since the late 80's, and experimental results (early work of Tick, VanRoy, etc.) that proved that with this information things could be sped up to essentially C speed.
Interestingly, the original design of Mercury implied compulsory declarations, and argued strongly for them. Over time the Mercury designers have progressively allowed fewer declarations, turning more towards inference (and, we argue, towards the Ciao model :-)), although the Mercury language itself still keeps the restrictions.
Is it possible to add an option to Ciao Prolog to generate mode and type inference? Of course, it is possible. I think I should rephrase the question. Do you have plans to add mode and type inference to Ciao-Prolog?
Actually, Ciao does have mode and type inference! This is done by the Ciao preprocessor 'ciaopp' (which contains our 'abstract interpreter', PLAI, which --please allow us some bragging-- was arguably the first tool ever to do this task in a truly practical way). In fact, ciaopp can also do many other things --I have included ciaopp's README at the end of the message for those who are curious, and also a pointer a paper which explains in more detail the functionality of ciaopp and has references.
Ciaopp has been available for quite a while for research purposes (and is used by us and by many other people). Unfortunately, up to now we have concentrated on getting a high-quality, well documented system, with a large set of libraries (i.e., Ciao itself, and the lpdoc autodocumenter). We have not had the time to make ciaopp as stable as the rest of Ciao (and we are always experimenting with it, because it is our main research platform). This is why we have not put it yet for download at the Ciao distribution site (we provide it on demand, if/when we have a more or less stable version through our Beta site). However, we should have an official distribution soon. The current version works with ciao-1.6 and we are finishing the version that runs with 1.8 (which has just been released).
Now, for the other side of things: once types, modes, etc. are available (whether inferred or declared) is to generate optimized code, i.e., to get the speedups. You have experience in this:
With this off-hand scheme, I was able to compile only very simple programs. However, they proved to be as fast as equivalent programs in Mercury.
Very interesting! As Manuel Carro mentioned in his message, we have also been working in this direction for a while and have prototypes which confirm your experiments (and that of the others mentioned above and our early intuition when we designed Ciao): if you use the inferred information you can achieve Mercury speed. The problem in getting a truly production-quality system is again that we have limited resources, and it takes a while to have a system that is as stable as the emulator in the Ciao distribution (which, by the way, stems from a circa '87 SICStus emulator).
Would you accept volunteers? I am sending copies of this letter to Dr. Cedric and Dr. Marcus. They know well the kind of programs I write, and they may make suggestions. I am also sure that they would be happy to work as volunteers in your Prolog to C compiler, if you accept volunteers, of course.
Yes, it seems like we have grounds for collaboration. Also, there are several people in the world working on these topics (not necessarily for Ciao, but on the general problem). Bart Demoen for example is also working on this very subject. We look forward to exchanging more technical details on how the different pieces that we have fit right now.
Cheers,
Manuel Hermenegildo
PS: We would be very interested in getting your program so that we can analyze where the speed differential is coming from. Is it possible to get a copy of it?
*** The ciaopp readme:
README
`ciaopp' is the precompiler of the Ciao Prolog development environment. `ciaopp' can perform a number of program debugging, analysis and source-to-source transformation tasks on (Ciao) Prolog programs. These tasks include:
Inference of properties of the predicates and literals of the progam, including types, modes and other variable instantiation properties, non-failure, determinacy, bounds on computational cost, bounds on sizes of terms in the program, etc.
Certain kinds of static debugging, finding errors before running the program. This includes checking the ways in which programs call the system library predicates and also checking the assertions present in the program or in other modules used by the program. Such assertions essentially represent partial specifications of the program.
Several kinds of source to source program transformations such as program specialization, program parallelization (including granularity control), inclusion of run-time tests for assertions which cannot be checked completely at compile-time, etc.
The information generated by analysis, the assertions in the system libraries, and the assertions optionally included in user programs as specifications are all written in the same assertion language, which is in turn also used by the Ciao system documentation generator, `lpdoc'.
`ciaopp' is distributed under the GNU general public license.
*** A basic reference on ciaopp (has also pointers to related papers, many available from http://www.clip.dia.fi.upm.es/):
@inproceedings{ciaopp-iclp99-tutorial, author = {M.~Hermenegildo and F.~Bueno and G.~Puebla and P.~Lopez-Garcia}, title = {Program Analysis, Debugging and Optimization Using the Ciao System Preprocessor}, booktitle = {1999 International Conference on Logic Programming}, year = {1999}, month = {November}, pages = {52--66}, publisher = {MIT Press}, address = {Cambridge, MA} }
I cannot add anything to explanations why CIAO (or GNU-Prolog) would be 40 to 200 times slower than Mercury, but first of all, according to the authors of Mercury (Zoltan Somogyi in the first place) the speed of Mercury comes from modes first, then types, then determinism. Next, being in the business of implementing a fast Prolog system myself, I am very (no, VERY, VERY, VERY) much interested in your program, because it might teach us - Prolog implementors - something real important. If you would be willing to make your application (as it runs in GNU and/or CIAO) available, I will be most grateful. This is not just academic interest: I am working on a Prolog like backend for HAL (a Mercury like language, but with a real logical variable - and other goodies which are not so important probably because you have your application running in plain Mercury). This backend (hProlog) is a bit speedier than its equals, but not by a factor of 40 to 200. Still, we have a project going on for using (declared or inferred) information in the emulator and a native code backend (we'll skip C :-). Just to tell you I am really interested.
An afterthought: a factor 40 to 200 seems weird, because Mercury reports usually contain a factor of 10 comparing with SICStus native code. Knowing the ratio (SISCtus native code/emulator) I find a factor 200 really interestingly high and once more, please can we get the programs with which you tested this ?
Cheers
Bart Demoen
ps. someone wrote
maybe determinism (or, better, the lack of it) might be the culprit: some cuts properly placed, and using indexing on the first argument, might help
unfortunately this is true, but also this I can find out relatively easily, because I am also involved in a Prolog system that does better than first argument indexing (ilProlog; not open source to everyone unfortunately, but I can use it for finding out stuff) ============================================================================== Message: Address: Action: help majordomo(a)clip.dia.fi.upm.es Info. on useful commands subscribe ciao-users-request(a)clip.dia.fi.upm.es Subscribe to this list unsubscribe ciao-users-request(a)clip.dia.fi.upm.es Unsubscribe from this list <whatever> ciao-users(a)clip.dia.fi.upm.es Send message to list ----------------------------------------------------------------------------- Archived messages: http://www.clip.dia.fi.upm.es/Mail/ciao-users/ -----------------------------------------------------------------------------
Hi.
Actually, Bart would not be the only one interested. I'd like to have a look myself ;-).
BTW, my congrats to the CIAO people for all their greta work!
Cheers,
Vitor ============================================================================== Message: Address: Action: help majordomo(a)clip.dia.fi.upm.es Info. on useful commands subscribe ciao-users-request(a)clip.dia.fi.upm.es Subscribe to this list unsubscribe ciao-users-request(a)clip.dia.fi.upm.es Unsubscribe from this list <whatever> ciao-users(a)clip.dia.fi.upm.es Send message to list ----------------------------------------------------------------------------- Archived messages: http://www.clip.dia.fi.upm.es/Mail/ciao-users/ -----------------------------------------------------------------------------
Actually, Bart would not be the only one interested. I'd like to have a look myself ;-).
We at UPM too --- as I said in my first message.
BTW, my congrats to the CIAO people for all their greta work!
Thanks a lot in the name of the whole team, Vitor.