Difference between revisions of "Climb"

From LRDE

 
(40 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
It appears that if all the projects of the LRDE involve various application areas, a common underlying problem is how
 
It appears that if all the projects of the LRDE involve various application areas, a common underlying problem is how
to reconcile two aspects that are usually contradictory : '''« performance and genericity »'''.
+
to reconcile two aspects that are usually contradictory: ''performance and genericity''.
   
This issue has led the lab's teams to develop a long-term software engineering based on technical C + + with
+
This issue has led the lab's teams to develop a long-term software engineering based on technical C++ with
many templates. This language does not only offer advantages. Disadvantages include the fact that C + + is a heavy language with
+
many templates. This approach has its drawbacks. Disadvantages include the fact that C++ is a heavy language with
 
an extremely complex and ambiguous syntax, that the template system is actually a completely different language from ''standard''
 
an extremely complex and ambiguous syntax, that the template system is actually a completely different language from ''standard''
C + + , and finally that it is a static language. This last point has significant implications on the application, insofar as it imposes a
+
C++, and finally that it is a static language. This last point has significant implications on the application, insofar as it imposes a
 
strict chain of Compilation => Development => Run => Debug, making for example rapid prototyping or human-machine interfacing
 
strict chain of Compilation => Development => Run => Debug, making for example rapid prototyping or human-machine interfacing
 
activities difficult. It becomes therefore essential to equip the involved projects with a third language infrastructure
 
activities difficult. It becomes therefore essential to equip the involved projects with a third language infrastructure
 
that is rather based on scripting languages.
 
that is rather based on scripting languages.
   
Facing these problems, another team of the laboratory has chosen to focus on the persistent question of '''« performance and genericity »'''
+
Facing these problems, another team of the laboratory has chosen to focus on the persistent question of ''performance and genericity''
with a '''transversal approach''', that is to say focused on alternative languages rather than on a particular application domain.
+
with a ''transversal approach'', that is to say focused on alternative languages rather than on a particular application domain.
The purpose of this research is therefore to examine the solutions offered by languages other than C + +, especially dynamic languages,
+
The purpose of this research is therefore to examine the solutions offered by languages other than C++, especially dynamic languages, and we chose Common Lisp.
and we chose Climb.
 
   
==== '''Perfomance''' ====
+
== '''Performance''' ==
   
At first glance, it seems paradoxical indeed to use, for performance issues, a language which is legitimately expected to ''deteriorate'' them. By definition,
+
At first glance, it seems paradoxical indeed to use, for performance issues, a language which is legitimately expected to ''deteriorate'' them. Almost by definition,
a dynamic language does less for the compilation and more for the execution (eg, type checking). Most ''modern'' dynamic languages like Python and Ruby
+
a dynamic language does less at compile-time and more at run-time (eg, type checking). Most ''modern'' dynamic languages like Python and Ruby
match these preconceived notions. Climb has however the unknown particularity to enable a data type of variables, instead of the traditional dynamic typing
+
match these preconceived notions. Common Lisp, however, has this ability to let you static type pieces of the code you write, and let the rest be dynamically typed. A compiler that is properly informed about such types is then free to perform
 
any possible optimization, even to produce a weakly typed executable as a C compiler would do.
of objects. A compiler that is properly informed about the type of a piece of code (you can freely combine static and dynamic typing) is then free to perform
 
any optimizations you want, even to produce a weakly typed executable like the one produced by a C compiler.
 
   
One goal of this research focuses therefore on comparing the performances obtained by some Climb compilers with those of equivalent programs written in
+
Therefore, one goal of this research focuses on comparing the performance obtained by some Common Lisp compilers with those of equivalent programs written in
 
C or C++. This work involves a substantial set of performance measurements on micro-benchmarks to evaluate the cost of some basic operations (arithmetic,
 
C or C++. This work involves a substantial set of performance measurements on micro-benchmarks to evaluate the cost of some basic operations (arithmetic,
 
object instantiation, access to their members, dynamic dispatch, etc.).
 
object instantiation, access to their members, dynamic dispatch, etc.).
   
==== '''Genericity''' ====
+
== '''Genericity''' ==
   
 
Once the issue of performance is resolved, we still have to demonstrate the benefits of a dynamic language for genericity. The basis of this approach lies
 
Once the issue of performance is resolved, we still have to demonstrate the benefits of a dynamic language for genericity. The basis of this approach lies
 
in a fact that is this time widely recognized: dynamic languages are more expressive. By eliminating especially the static typing, and consequently, by expanding the scope
 
in a fact that is this time widely recognized: dynamic languages are more expressive. By eliminating especially the static typing, and consequently, by expanding the scope
of polymorphism, dynamic languages provide paradigms that are impossible or difficult to obtain in static languages. If we take simply the paradigm of object-oriented programming, Climb goes further than other (static or dynamic) languages if the object layer is based on a protocol called ''meta-object'': a reflexive architecture that implements the object layer in itself, and that also allows to modify or extend it. Thus, far from the classical object approach of common languages, the object-oriented expressivity of Climb includes natively multimethods, and allows the use of traditional classes or the model based on the notion of prototype, a context-oriented approach, etc.
+
of polymorphism, dynamic languages provide paradigms that are impossible or difficult to obtain in static languages. If we take simply the paradigm of object-oriented programming, Common Lisp goes further than other (static or dynamic) languages if that the object layer is based on a so-called ''meta-object protocol'': a reflexive architecture that implements the object layer in itself, and that also allows to modify or extend it. Thus, far from the classical OO approach of traditional languages, the object-oriented layer of Common Lisp includes natively multimethods, and allows the use (and mix) of traditional classes-based, prototype-based, context-oriented approaches, etc.
   
 
The second line of research in this work consists in the study of all these new programming paradigms in terms of what they bring to the notion of genericity.
 
The second line of research in this work consists in the study of all these new programming paradigms in terms of what they bring to the notion of genericity.
 
To do this, we have chosen to ''clone'' one of the oldest projects of the laboratory ([[Olena]]) and to express the same issues following an axis of dynamic genericity.
 
To do this, we have chosen to ''clone'' one of the oldest projects of the laboratory ([[Olena]]) and to express the same issues following an axis of dynamic genericity.
   
Finally, a longer-term perspective will be to reconcile these aspects of dynamic genericity with the performances of a dedicated code. This step should also be made significantly easier than the manipulation of C + + templates because of the structural reflexivity of Lisp (code and data are represented in the same way). The system of "macros'' in
+
Finally, a longer-term perspective will be to reconcile these aspects of dynamic genericity with the performances of a dedicated code. This step should also be made significantly easier than the manipulation of C++ templates because of the structural reflexivity of Lisp (code and data are represented in the same way). The system of ''macros'' in
Climb is unique because it can perform any function written in Lisp itself during the compilation, these functions themselves having access to the code to compile. This allows in particular to rewrite the code on the fly and an easy compilation just in time.
+
Common Lisp is unique because it can perform any function written in Lisp itself during the compilation, these functions themselves having access to the code to compile. This allows in particular to rewrite the code on the fly and provides for native JIT-compilation.
   
==== Publications ====
+
== '''Publications''' ==
  +
  +
{{Publications/ProjectList|Climb}}
  +
  +
<!--
  +
===== Conferences =====
  +
  +
{{#ask: [[Category:Publications]] [[Publication type::inproceedings]] [[Has author::~*Didier Verna*]] [[Published in::!~Onward*]] [[Published in::!TUGboat]] [[News date::>2006-01-01]]
  +
| ?Has title=title
  +
| ?Has bibtex id=id
  +
| ?News subtitle=subtitle
  +
| ?News date#MEDIAWIKI=date
  +
| format = ul
  +
| template = PublicationItem
  +
| order = descending
  +
| sort = News date
  +
| named args = yes
  +
}}
  +
  +
===== Journals =====
  +
{{#ask: [[Category:Publications]] [[Publication type::article]] [[Has author::~*Didier Verna*]] [[News date::>2006-01-01]]
  +
| ?Has title=title
  +
| ?Has bibtex id=id
  +
| ?News subtitle=subtitle
  +
| ?News date#MEDIAWIKI=date
  +
| format = ul
  +
| template = PublicationItem
  +
| order = descending
  +
| sort = News date
  +
| named args = yes
  +
}}
  +
  +
===== Book chapter =====
  +
  +
{{#ask: [[Category:Publications]] [[Publication type::incollection]] [[Has author::~*Didier Verna*]] [[News date::>2006-01-01]]
  +
| ?Has title=title
  +
| ?Has bibtex id=id
  +
| ?News subtitle=subtitle
  +
| ?News date#MEDIAWIKI=date
  +
| format = ul
  +
| template = PublicationItem
  +
| order = descending
  +
| sort = News date
  +
| named args = yes
  +
}}
  +
-->

Latest revision as of 13:09, 11 June 2019

It appears that if all the projects of the LRDE involve various application areas, a common underlying problem is how to reconcile two aspects that are usually contradictory: performance and genericity.

This issue has led the lab's teams to develop a long-term software engineering based on technical C++ with many templates. This approach has its drawbacks. Disadvantages include the fact that C++ is a heavy language with an extremely complex and ambiguous syntax, that the template system is actually a completely different language from standard C++, and finally that it is a static language. This last point has significant implications on the application, insofar as it imposes a strict chain of Compilation => Development => Run => Debug, making for example rapid prototyping or human-machine interfacing activities difficult. It becomes therefore essential to equip the involved projects with a third language infrastructure that is rather based on scripting languages.

Facing these problems, another team of the laboratory has chosen to focus on the persistent question of performance and genericity with a transversal approach, that is to say focused on alternative languages rather than on a particular application domain. The purpose of this research is therefore to examine the solutions offered by languages other than C++, especially dynamic languages, and we chose Common Lisp.

Performance

At first glance, it seems paradoxical indeed to use, for performance issues, a language which is legitimately expected to deteriorate them. Almost by definition, a dynamic language does less at compile-time and more at run-time (eg, type checking). Most modern dynamic languages like Python and Ruby match these preconceived notions. Common Lisp, however, has this ability to let you static type pieces of the code you write, and let the rest be dynamically typed. A compiler that is properly informed about such types is then free to perform any possible optimization, even to produce a weakly typed executable as a C compiler would do.

Therefore, one goal of this research focuses on comparing the performance obtained by some Common Lisp compilers with those of equivalent programs written in C or C++. This work involves a substantial set of performance measurements on micro-benchmarks to evaluate the cost of some basic operations (arithmetic, object instantiation, access to their members, dynamic dispatch, etc.).

Genericity

Once the issue of performance is resolved, we still have to demonstrate the benefits of a dynamic language for genericity. The basis of this approach lies in a fact that is this time widely recognized: dynamic languages are more expressive. By eliminating especially the static typing, and consequently, by expanding the scope of polymorphism, dynamic languages provide paradigms that are impossible or difficult to obtain in static languages. If we take simply the paradigm of object-oriented programming, Common Lisp goes further than other (static or dynamic) languages if that the object layer is based on a so-called meta-object protocol: a reflexive architecture that implements the object layer in itself, and that also allows to modify or extend it. Thus, far from the classical OO approach of traditional languages, the object-oriented layer of Common Lisp includes natively multimethods, and allows the use (and mix) of traditional classes-based, prototype-based, context-oriented approaches, etc.

The second line of research in this work consists in the study of all these new programming paradigms in terms of what they bring to the notion of genericity. To do this, we have chosen to clone one of the oldest projects of the laboratory (Olena) and to express the same issues following an axis of dynamic genericity.

Finally, a longer-term perspective will be to reconcile these aspects of dynamic genericity with the performances of a dedicated code. This step should also be made significantly easier than the manipulation of C++ templates because of the structural reflexivity of Lisp (code and data are represented in the same way). The system of macros in Common Lisp is unique because it can perform any function written in Lisp itself during the compilation, these functions themselves having access to the code to compile. This allows in particular to rewrite the code on the fly and provides for native JIT-compilation.

Publications