* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* *
* Your message has NOT been delivered to the scsc.ethz.ch domain. *
* This message was generated by the automatic mail answering service *
* of the ETHZ. Your original message is appended to this reply. *
* *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* *
* Swiss Center for Scientific Computing (SCSC) *
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *
* *
* Your message has been rejected because the SCSC Scientific Projects *
* and Support section has been disbanded as of October 1999. *
* *
* The members of the SPS section have moved to the following domains: *
* *
* Amon, Beat -> ammon@ginnan.issp.u-tokyo.ac.jp *
* Bregy, Nicole -> bregy@finance.ch *
* Chisholm, Rory -> rchishol@iiic.ethz.ch *
* de Forcrand, Philippe -> forcrand@itp.phys.ethz.ch *
* de Sturler, Alice -> alice@csar.uiuc.edu *
* de Sturler, Eric -> sturler@csar.uiuc.edu *
* Favre, Jean -> favre@cscs.ch *
* Fischer, Thomas -> tfischer@ccu1.auckland.ac.nz *
* Flukiger, Peter -> peter.flukiger@reuters.com *
* Friedli, Armin -> friedli@awu.id.ethz.ch *
* Groh, Gabor -> groh@cscs.ch *
* Gutknecht, Martin H. -> martin.gutknecht@sam.math.ethz.ch *
* Hanf, Martin -> hanf@finance.ch *
* Hansmann, Uli -> hansmann@ims.ac.jp *
* Hilger, Anouk -> Anouk.M.Hilger@lux.dupont.com *
* Klopper, Wim -> w.m.klopper@kjemi.uio.no *
* Krasnitz, Alex -> krasnitz@hetws3.nbi.dk *
* Laliena, Victor -> laliena@posta.unizar.es *
* Lienhart, Brigitte -> lienhart@finance.ch *
* Loher, Damian -> loher@sam.math.ethz.ch *
* Luethi, Hans Peter -> luethi@igc.phys.chem.ethz.ch *
* Millard, Patricia -> millard@itp.phys.ethz.ch *
* Peikert, Ronald -> peikert@inf.ethz.ch *
* Petersen, Wesley P. -> wesley.petersen@sam.math.ethz.ch *
* Portmann, Stefan -> portmann@igc.phys.chem.ethz.ch *
* Ressel, Klaus -> kjr@dfd.dlr.de *
* Roth, Martin -> martin.roth@inf.ethz.ch *
* Rozloznik, Miroslav -> rozloznik@sam.math.ethz.ch *
* Schlegel, Elisabeth -> schlegel@sl.ethz.ch *
* Schnidrig, Remo -> schnidrig@finance.ch *
* Therre, Jean-Pierre -> therre@swissonline.ch *
* van der Sijs, Arjan -> arjan.van.der.sijs@asml.nl *
* von Bueren, Daniel -> dvb@visdome.ethz.ch *
* von Sturler, Alice -> alice@csar.uiuc.edu *
* von Sturler, Eric -> sturler@csar.uiuc.edu *
* Wuertz, Diethelm -> wuertz@itp.phys.ethz.ch *
* *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* *
* In case of technical problems, please contact postmaster@ethz.ch *
* *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
attached mail follows:
oon-digest Wednesday, November 3 1999 Volume 01 : Number 050
* In this issue:
OON: OON Conferences coming up?
OON: Experience with Eiffel?
Re: OON: Experience with Eiffel?
Re: OON: Experience with Eiffel?
Re: OON: Experience with Eiffel?
Re: OON: Experience with Eiffel?
Re: OON: Experience with Eiffel?
Re: OON: Experience with Eiffel?
----------------------------------------------------------------------
Date: 22 Oct 1999 11:17:20 -0400
From: Paul Stodghill <stodghil@CS.Cornell.EDU>
Subject: OON: OON Conferences coming up?
Does anyone have any CFP for upcoming OON conferences? The paper deadlines
for the conferences listed on the oonumerics web page have all passed...
Thanks.
- --
Paul Stodghill <stodghil@cs.cornell.edu>
Dept. of Computer Science, Upson Hall, Ithaca, NY 14853
Phone: 607-254-8838 FAX: 607-255-4428
http://www.cs.cornell.edu/stodghil/
------------------------------
Date: Tue, 2 Nov 1999 19:58:09 +0200
From: Jonas Juselius <jonas@iki.fi>
Subject: OON: Experience with Eiffel?
Hello,
I'm wondering if anyone has any experience with eiffel for scientific
programming. I would be very happy to hear about pros and cons of using
eiffel, instead of some more "established" language as for example f90 or C++.
I would also greatly appreciate any benchmarks for raw number crunching
applications written in eiffel. My field of interest is in quantum chemistry,
where performance means a great deal, since calculations tend to run for
about one hour to a month...
I personally dislike fortran for a number of reasons, and I think C++ is plain
ugly and convoluted. Most of the time I try to stick to my all
time favorite language, python, but when python/C is not fast enough I usually
go for C++ or f90. A couple of days ago I stumbled over eiffel, and I got
really impressed. But before investing more time in eiffel, I would like to
know if it's worth it...
Best regards,
jonas
I hope I didn't step on anybodys toes with my comments on C++ and f90... :-)
- --
And what is good, Phaedrus,
And what is not---
Need we ask anyone to tell us these things?
[ PGP public key: finger jonas@radon.pc.helsinki.fi ]
------------------------------
Date: Tue, 2 Nov 1999 13:38:16 -0500 (EST)
From: Todd Veldhuizen <tveldhui@extreme.indiana.edu>
Subject: Re: OON: Experience with Eiffel?
Jonas Juselius wrote:
> I'm wondering if anyone has any experience with eiffel for scientific
> programming.
Paul Dubois wrote a book about this:
@BOOK { Dubois97,
AUTHOR = "Paul F. Dubois",
TITLE = "Object technology for scientific computing",
YEAR = "1997",
ANNOTE = "From the preface:
I would like this book to serve scientists who are considering the
application of object technology to scientific programs. In addition, I would
like to assist those who are combining Fortran or C with the Eiffel language
or who are writing programs in Eiffel that use mathematical or statistical
software. Here is how I have organized the information:
Part I reviews traditional methods of developing scientific software. I
explain some of the principal ideas behind object-oriented programming with
examples from a scientific point of view. I introduce the Eiffel Method and
discuss the features of Eiffel and C++ that are of importance to the
scientific programmer.
Part II explains the practical details about the task of combining existing
programs in Fortran, C, or C++ with Eiffel. This information about Eiffel is
not widely available nor explained elsewhere in as much detail. I also
discuss nuances of Fortran/C interaction.
Part III presents EiffelMath, a library of proven mathematical algorithms
developed by the Numerical Algorithms Group, Oxford, UK, now available to
Eiffel users. Even scientists who are not yet Eiffel users may find it
interesting to see how groups of mathematical algorithms can be related and
packaged into easy-to-use software components.
The compact disk that accompanies this book offers free versions of
Interactive Software Engineerings Eiffel compiler for most Unix systems,
including Linux. (Instructions are also provided for obtaining Windows
versions via FTP). Also included are all of the test routines I used to
create EiffelMath. These routines illustrate proper use of the library and
Eiffel, but they may also be modified by scientists to solve problems in
their area of interest."
}
Cheers,
Todd
- --
Todd Veldhuizen tveldhui@acm.org
Indiana Univ. Comp. Sci. http://extreme.indiana.edu/~tveldhui/
------------------------------
Date: Tue, 2 Nov 1999 14:43:36 -0800 (PST)
From: Phil Austin <phil@geog.ubc.ca>
Subject: Re: OON: Experience with Eiffel?
Todd Veldhuizen writes:
> Jonas Juselius wrote:
> > I'm wondering if anyone has any experience with eiffel for scientific
> > programming.
>
> Paul Dubois wrote a book about this:
>
Two (related) caveats:
1) the book is out of print
2) a big reason for 1) is that to run the code you needed
to purchase both the ISE Eiffel compiler and their IMSL package,
which came to more than $US 700/seat.
But www.abebooks.com shows that there's a copy for sale for $US 17
from a bookstore in Kearny, NJ.
If you buy it, note that there is a free Eiffel compiler (small
Eiffel), as well as new signs of life at comp.lang.sather,
which is an Eiffel offshoot developed mainly for scientific
computing.
Regards, Phil
------------------------------
Date: Wed, 03 Nov 1999 10:44:58 +0000
From: "Peter Hamer" <pgh@nortelnetworks.com>
Subject: Re: OON: Experience with Eiffel?
Jonas Juselius wrote:
> I'm wondering if anyone has any experience with eiffel for scientific
> programming.
Sorry, no. But some thought on languages in general.
> I would be very happy to hear about pros and cons of using
> eiffel, instead of some more "established" language as for example f90 or C++.
It is unlikely that you will get core maths routines to run faster than when they
are coded in Fortran. Partly because of traditional value-systems of compiler
writers, but mainly because the simplicity of Fortran enables many optimisations
to be blindly applied (you need complex anti-aliasing tests for C etc). I say
this with some regret as someone who usually codes in C or C++.
IMHO Eiffel is a very nice language, which never caught on.
> I would also greatly appreciate any benchmarks for raw number crunching
> applications written in eiffel. My field of interest is in quantum chemistry,
> where performance means a great deal, since calculations tend to run for
> about one hour to a month...
In general Fortan outperforms C & C++. Some complex use of templates to
achieve compile-time optimisation enable some C++ code to rival Fortan.
Don't know about Eiffel, but expect it's closer to C. In general, language
designers and compiler writers don't concentrate on number-crunching
performance.
> I personally dislike fortran for a number of reasons, and I think C++ is plain
> ugly and convoluted..
No arguments. But there is a lot of good code out there in these languages.
If you use a suitable compiler system (GNUs is free) you can inter-link
Fortan, C & C++.
> Most of the time I try to stick to my all
> time favorite language, python, but when python/C is not fast enough I usually
> go for C++ or f90. A couple of days ago I stumbled over eiffel, and I got
> really impressed. But before investing more time in eiffel, I would like to
> know if it's worth it...
With your background, I would be tempted to stick to python+something.
Trying hard to make the something rely heavily on public-domain highly
optimised maths libraries (eg LAPACK, CLAPACK, or whatever libraries
address what is taking `about one hour to a month' of CPU time). There is
presumably some kernel activities that are eating time, and which may
require thoughtful optimization (LAPACK can be tuned to optimise use
of the CPU cache and the memory paging system by re-organising the
calculations it needs to perform).
I assume that you have instrumented the program so you know where
the time is going? Is there any memory-thrashing? Do you know the
order of your algorithms [eg o(N*log(N))].
Peter
BTW if you can spare the time you might like to look at the NS simulator
as an example of dual-implementation. They use octl for the interface and
C++ for the internals, in general each entity-type consists of an octl class
and a C++ class. You may like the idea, or it may give you thoughts on
how Python is best used with `something'.
See http://www-mash.cs.berkeley.edu/ns
especially (iff I remember correctly) some of the workshop slides.
------------------------------
Date: Wed, 3 Nov 1999 07:20:54 -0700 (MST)
From: "Kent Budge" <kgbudge@valinor.sandia.gov>
Subject: Re: OON: Experience with Eiffel?
Peter Hamer wrote:
> Jonas Juselius wrote:
>
> > I'm wondering if anyone has any experience with eiffel for scientific
> > programming.
>
> Sorry, no. But some thought on languages in general.
>
> > I would be very happy to hear about pros and cons of using
> > eiffel, instead of some more "established" language as for example f90 or C++.
>
> It is unlikely that you will get core maths routines to run faster than when they
>
> are coded in Fortran. Partly because of traditional value-systems of compiler
> writers, but mainly because the simplicity of Fortran enables many optimisations
> to be blindly applied (you need complex anti-aliasing tests for C etc). I say
> this with some regret as someone who usually codes in C or C++.
>
> IMHO Eiffel is a very nice language, which never caught on.
>
...
I'm not an experienced Eiffel programmer, but I've studied the language.
My take is this:
About 30% of C++ is beautiful. The other 70% is excessively baroque,
largely for the sake of C compatibility, but I'm willing to live with
it. There is a significant scientific C++ community. These
considerations make C++ a viable alternative to FORTRAN, and it is the
language I routinely use.
About 95% of Eiffel is beautiful. The other 5% is intolerable. (Try
writing a complex number class in Eiffel.) Since there is not yet a
significant scientific Eiffel community, and since I'm still pulling arrows
out of my back from having pioneered C++ in my workplace, I'm unwilling
to invest much effort in working around the obnoxious 5% of Eiffel, even
for the other, truly beautiful, 95%.
------------------------------
Date: Wed, 03 Nov 1999 12:11:48 -0700
From: Steve Karmesin <karmesin@lanl.gov>
Subject: Re: OON: Experience with Eiffel?
Peter Hamer wrote:
> In general Fortan outperforms C & C++. Some complex use of templates to
> achieve compile-time optimisation enable some C++ code to rival Fortan.
> Don't know about Eiffel, but expect it's closer to C. In general, language
> designers and compiler writers don't concentrate on number-crunching
> performance.
I guess the question here is whether Eiffel supports the types of things that
you use in C++ to get the sort of compile time optimizations that end up
rivaling FORTRAN. As ugly as the C++ template system is, it allows you to
express a great deal at compile time, which is what you need.
What the compiler can do with your code is entirely a function of how much
information you give it. A lot of C++'s complexity comes from the fact that
there are a lot of things you can tell the compiler about your code, and it
can use that to make it go fast. If there are fewer things you can tell the
optimizer, it will have to be conservative and generate slower code.
Given that, the outstanding issue that keeps C/C++ from being as fast as
FORTRAN is pointer aliasing. When you pass arrays to a subroutine in FORTRAN
you are implicitly guaranteeing that they are not aliased, and this gives the
compiler much wider latitude in optimization. Does Eiffel have a way to
express lack of aliasing?
Another possible issue is one that I simply don't know the answer to.
Operator overloading is a big benefit (and a source of complexity) in C++. It
lets you write a transparent complex number class, and if you work hard you
can build arrays like F90's. On some level this is syntactic sugar, but it is
really important. Mathematical expressions can be very complicated, and
something like:
a = b+c*d/2-x*y;
is *vastly* easier to maintain than
assign( a , plus(b,subtract(divide(mult(c,d),2),mult(x,y))));
- - Steve Karmesin
------------------------------
Date: Wed, 03 Nov 1999 18:53:25 +0000
From: "Peter Hamer" <pgh@nortelnetworks.com>
Subject: Re: OON: Experience with Eiffel?
Steve Karmesin wrote:
> Peter Hamer wrote:
>
> > In general Fortan outperforms C & C++. Some complex use of templates to
> > achieve compile-time optimisation enable some C++ code to rival Fortan.
> > Don't know about Eiffel, but expect it's closer to C. In general, language
> > designers and compiler writers don't concentrate on number-crunching
> > performance.
>
> I guess the question here is whether Eiffel supports the types of things that
> you use in C++ to get the sort of compile time optimizations that end up
> rivaling FORTRAN. As ugly as the C++ template system is, it allows you to
> express a great deal at compile time, which is what you need.
I would doubt it. It is pretty certain that the definers of the C++ templates
did not anticipate the use to which they could be put. [I'm talking about
the numerical communities loop-unrolling, etc with templates which seems
to me way outside the original intentions of templates.]
> What the compiler can do with your code is entirely a function of how much
> information you give it. A lot of C++'s complexity comes from the fact that
> there are a lot of things you can tell the compiler about your code, and it
> can use that to make it go fast. If there are fewer things you can tell the
> optimizer, it will have to be conservative and generate slower code.
I'm not certain that go-fast is really part of C++ design philosophy. Does
it really offer any advantages to compiler optimisation over C?
IMHO OO is mainly for things like clarity of expression and information hiding.
And you hope that you don't pay too high a run-time price for it. Usually you
don't.
> Given that, the outstanding issue that keeps C/C++ from being as fast as
> FORTRAN is pointer aliasing. When you pass arrays to a subroutine in FORTRAN
> you are implicitly guaranteeing that they are not aliased, and this gives the
> compiler much wider latitude in optimization. Does Eiffel have a way to
> express lack of aliasing?
A good question.
> Another possible issue is one that I simply don't know the answer to.
> Operator overloading is a big benefit (and a source of complexity) in C++. It
> lets you write a transparent complex number class, and if you work hard you
> can build arrays like F90's. On some level this is syntactic sugar, but it is
> really important. Mathematical expressions can be very complicated, and
> something like:
>
> a = b+c*d/2-x*y;
>
> is *vastly* easier to maintain than
>
> assign( a , plus(b,subtract(divide(mult(c,d),2),mult(x,y))));
Operator overloading is a big plus in clarity of expression, which is one of
the aims of OO languages.
However user-defined-operators (infix or prefix) can be slow to execute,
not least because of all the temporary variables that need to be created
and destroyed. This can be a big hit if a, b, c, d, x & y are huge matricies.
Even messier if tou want to allow for some of the matricies being of special
types (eg triangular, band, ...).
Sadly, obscure routines that do in-place matrix updates (in a nice order
w.r.t memory layout) can be a lot faster.
Peter
------------------------------
End of oon-digest V1 #50
************************
--------------------- Object Oriented Numerics List --------------------------
* To subscribe/unsubscribe: use the handy web form at
http://oonumerics.org/oon/
* If this doesn't work, please send a note to owner-oon-list@oonumerics.org
--------------------- Object Oriented Numerics List --------------------------
* To subscribe/unsubscribe: use the handy web form at
http://oonumerics.org/oon/
* If this doesn't work, please send a note to owner-oon-list@oonumerics.org
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:09 EST