Hello...
My question is about .NET architecture when it comes to scientific programming.
I want to know what are the advantages and the disadvantages when using the
dotNET framework instead of other legacy languages (especially C++ and
Fortran). 
I am also concerned about mathematical calculations (speed,ease of
code implementation etc). The answer must be specific to "real world problems" 
and not limited to abstract terms like OOP, encapsulation etc. 
For example: access to the CLR doesn't decrease the execution speed 
dramatically unlike native apps? Is that a major disadvantage or is it 
compensated by an other feature?
Finally, are there any "scientific software" houses that are adopting .NET?
In other words, do you think that .NET is the programming future?
Thank you.

---

Request for Question Clarification by mathtalk-ga on 04 Jun 2004 18:11 PDT

Hi, nikolas-ga:

Still working on my essay, but I stumbled on a book draft that seems
especially on point regarding the distributed computing aspect of
scientific programming.

Prof. Gary Nutt (Univ. of Colorado) is working on a book about
Distributed Virtual Machines (DVM) and has made a draft of his
copyrighted work available here:

[Distributed Virtual Machines: Inside the Rotor CLI]
http://www.cs.colorado.edu/~nutt/DVM/

"The CLR can be though of as a leading edge design and implementation
of a distributed virtual machine (DVM) for handling the broad class of
distributed programming paradigms incorporated in .NET. This is a
trend that originally appeared in scientific programming domains, and
which was popularized by the Java and JVM technology. programming."

http://www.cs.colorado.edu/~nutt/DVM/Preface.pdf

Have a look!

regards, mathtalk-ga

---

Clarification of Question by nikolas-ga on 05 Jun 2004 02:59 PDT

Hi mathtalk-ga,
Thank you for the excellent link. It is really helpful in regard to
distributed computing. I will examine the available draft document and
I'll wait for your essay which must be superb!
Best regards,
nikolas-ga

Hi,nikolas-ga:

For a high-level discussion of what is .Net, see this previous Answer of mine:

[Q: Microsoft .NET technology]
http://answers.google.com/answers/threadview?id=209092

in which among other things I try to winnow the marketing aspects from
the technical aspects of .Net.

To address the definition of scientific programming, I thought it
would be fun to take a lighthearted approach.

With apologies to Dave Letterman and Jeff Foxworthy:


10. If you don't need no steenkin' user interface...

 9. If your code base for this project was written in Fortran in 1974...
 
 8. If your network administrator allots an extra half-terrabyte of
space at the first sign your data sets are feeling cramped...
 
 7. If you complain about "reinventing the wheel" but do it anyway
because it takes too long to read someone else's documentation...
 
 6. If you fill up three yellow pads with formulas and doodles before
writing any code...
 
 5. If you love the sound of numbers crunching softly in the background...
 
 4. If your program could run on a single CPU, given enough RAM, but
wouldn't finish before the Sun became a red giant...
 
 3. If your application crunches not only numbers, but letters, Greek
symbols, and even bits of punctuation...
 
 2. If you've about finished coding and figure it's time to decide
what you want the program to do...
 
 1. If you feel the need ... for speed,


THEN you might be a Scientific Programmer!!


* * * * * * * * * * * * * * * * * * * * * *
 
So let's tackle at least some of the main points:

1. The need for speed

While it would be silly to claim that the .Net platform rings the last
drop of operating efficiency out of our PC's, it is worthwhile to note
that performance was and is an important consideration.

Although losing in any assembler competition where the rules are
stacked in favor of doing one particularly well-defined thing in a
particularly fast way, the first "win" for .Net has to be performance
improvement over Java.  As a matter of fact there are many scientific
"applets" written in Java on the Web, and the sloth-like performance
of Java is legendary.  While slow response is often a complaint from a
user interaction perspective, surely in a number-crunching race it
must also be objectionable.

C# adopts many of the good things about Java, but packages them in a
compiled, actually Just-In-Time compiled (JIT) framework.  This means
that if C# code is written today, the .Net platform (really the CLR or
Common Language Runtime) can optimize it for future architectures
without programmer intervention.  This does have some implications for
proprietary code/intellectual property issues, but in terms of
performance it's advantage .Net.

Similarly these are advances over the .COM platform, which delivers
components "as is" and, while addressing some important aspects of
versioning, creates some substantial headaches on that account. 
Again, advantage .Net.

For some .Net performance diagnostic and optimization techniques, see here:

[Visual Studio .NET - Performance and Diagnostics]
http://msdn.microsoft.com/vstudio/using/understand/perf/default.aspx

2. What if analysis

One way that scientific programming tends to outdo the worst practices
of business software is in terms of change of scope.  Frequently we
"adaptively" change the purpose of programs in experimental mode
precisely because of what we have learned from the programs' initial
configuration.  So change management in scientific programming can be
complex.

The .Net platform inherits a component-based orientation to managing
complexity from .COM, but adds a "new" tactic which is called
"aspect-oriented programming" (AOP), a term coined by Gregor Kiczales
in 1997.  Microsoft explored this approach, which allows for certain
application-wide issues like security or thread management, to be
dealt with in circumspect fashion, ie. without having repetitive
code-snippets inserted all over the place to ensure such application
goals are met.  Their efforts were a key to realizing some of the .COM
programming deficiencies and led in due time to what become the .Net
initiative.

In a broader perspective "what if" analysis can be viewed as an
extreme sort of demand for code reuse.  Another buzzword that should
be mentioned in this connection is "intentional programming".  These
folks are a kind of Microsoft spin-off that are promoting one approach
to expressing the purpose of code in a non-procedural fashion, e.g by
annotations of "aspects" and attributes:

[Intentional Programming]
http://intentsoft.com/

3. Crunching more than just numbers

Today's scientific applications often include more than just
floating-point computations.  In the "bioinformatics" area, for
example, there is a lot of concern with finding "best matches" among
strings (e.g. of amino acid or nucleic acid units), which is a very
combinatorial sort of problem.

The good news here about .Net is its treatment of datatypes as a
first-class programming feature.  Unlike .COM, we have true
inheritance between .Net components and many other features (passing
objects, even remotely) that were a source of frustration with .COM.

For a thorough-going treatment see Don Box's book Essential .Net vol. 1 (CLR).


* * * * * * * * * * * * * * * * * * * * *

Additional Links:
=================


[Abstract: Debugging scientific applications in the .NET framework]
http://portal.acm.org/citation.cfm?id=860023&dl=ACM&coll=portal

[Harness the features of C# to Power Your Scientific Computing Projects]
http://www.msdnaa.net/content/?Scientific_Computing_Projects

---

Clarification of Answer by mathtalk-ga on 27 Jun 2004 13:09 PDT

Oops, somehow I posted the rest of my essay below as the third Comment.

?

regards, mathtalk-ga

Hi mathtalk-ga,
your answer, as expected, was excellent. I enjoyed the humorous
writing style with the terrific clarification of some very interesting
points. I would also like to mention a very interesting url for .NET
for basic linear algebra computations:
http://www.aisto.com/roeder/dotnet/.
I will certainly post some clarifications just to extend the dialog
and to add my personal experience. Thank you again... Keep in touch!
nikolas-ga

Hi, nikolas-ga:

The longevity of Fortran applications in scientific programming is
remarkable, but I'm not sure what it can tell us about the prospects
for future scientific software development under .Net frameworks.

I consider myself a scientific programmer and a .Net programmer, but
I'm not sure I see anything but overlap in the two characteristics. 
Here's a company that offers a .Net "scientific programming"
(mathematical) library:

[NMath]
http://www.centerspace.net/

Speed is certainly an issue in many scientific programming projects,
but it has gotten to the point where very large scale computations are
done through some cooperative programming archictectures
(loosely-coupled parallel programming).

Here there is perhaps the germ of an argument to be made for the .Net
framework, with its substantial support for XML/Soap protocols and
"distributed service" models of computation.

I could post a more detailed note on the performance impact, relative
to a single-user/single computer application, of restricting oneself
to the CLR and the .Net framework, but I'm not convinced such a narrow
approach to your Question would be helpful.

regards, mathtalk-ga

Hi mathtalk-ga,
thank you for the well written comment. Please post the detailed note
on the performance impact you are referring to, as well as your
personal experience regarding both worlds (.NET & COM). Emphasizing
examples of source code could be very helpful. I would also like to
have a list of advantages and disadvantages from the two sides if
that's not a problem.
Regards,
nikolas-ga

4.  Will it finish in our lifetime?

Or even the Sun's lifetime:

[How do you calculate the lifetime of the Sun?]
http://curious.astro.cornell.edu/question.php?number=389

Jerry Pournelle's visionary Law (one programmer, at least one CPU)
having become so thoroughly realized, we now set our sites on
massively parallel processing for even some relative "mundane" tasks
(like factoring big numbers or searching extraterrestrial life, say). 
All in a day's work for a scientific programmer.

We've already broached (in Comments) the message-passing paradigm of
.Net for handling remote procedure invocation.  Indeed the most urgent
need for cross-platform implementations of .Net have to do with
providing a CLR environment so that just such projects can get
underway.

Prof. Gary Nutt (Univ. of Colorado) is working on a book about
Distributed Virtual Machines (DVM) and has made a draft of his
copyrighted work available here:

[Distributed Virtual Machines: Inside the Rotor CLI]
http://www.cs.colorado.edu/~nutt/DVM/

"The CLR can be though of as a leading edge design and implementation
of a distributed virtual machine (DVM) for handling the broad class of
distributed programming paradigms incorporated in .NET. This is a
trend that originally appeared in scientific programming domains, and
which was popularized by the Java and JVM technology. programming."

http://www.cs.colorado.edu/~nutt/DVM/Preface.pdf

It may be repeated here that Microsoft has weighed in on the issue of
cross-platform/cross-process communications before, with varying
success.  An early Windows approach to cross-process communication was
DDE, which had a remote counterpart NetDDE, that is even today used in
a critical bootstrapping part of the .Net foundation.  Similarly with
COM and DCOM, and remote procedure calls (RPC protocol).  The .Net
platform doesn't replace these technologies as much as it subsumes and
completes them, esp. by adding the SOAP/XML protocol to the mix for a
better rounded methodology of defining objects (state (data) +
behavior (code)) in portable fashion.

5.,9.  Numbers, softly crunched, and Fortran - the legacy!

And who doesn't love this, esp. if it can be done in the background? 
But we begin to tread upon ground that has been thoroughly stomped
before .Net, and we may well ask what advantage .Net brings to the
party.

In order to guarantee code safety the CLR has to drastically curtail
any hope of "programming to the metal".  At the same time when it
comes to numerical linear algebra, say, there exist well-tested,
widely acknowledged libraries like BLAS/LAPACK, originally written to
Fortran targets:

[LAPACK - Linear Algebra PACKage]
http://www.netlib.org/lapack/

Despite ways to link .Net code to existing libraries, esp. if
presented through COM interfaces, it cannot be claimed that .Net
presents an advantage here.

Furthermore the Windows platform itself, at least in comparison to
DOS, Netware, or Linux, is something of a bloated consumer of system
resources, thus leaving less background for number crunching to run
in.

So, having come to the midpoint of our laundry list of scientific
programming issues, it's timely to admit .Net is not the magic bullet
of our dreams, the solution to every problem.  However there is a nice
project here that I'd like to propose.

Here's a paper by Jack Dongarra et al about converting LAPACK Fortran to Java:

[JLAPACK|Compiling LAPACK Fortran to Java (Doolin, Dongarra, Seymour)]
http://www.netlib.org/utk/people/JackDongarra/PAPERS/f2jrep~1.pdf

In the course of the project, which reworked an existing Fortran to C
conversion utility (f2c) into one for converting Fortran to Java
(f2j), it was observed that:

"The Fortran GOTO is hard to translate to Java source code because
Java does not support a goto statement at all."

The paper goes on to detail their approach, involving some
post-processing of libraries, to work around this.  My thought is that
since C# _does_ support the goto statement, an apt revistation would
be to develop a Fortran to C# conversion utility (f2cs?) that bypasses
this difficulty.

6.,7.  From design to implementation & reading old documentation

Documentation after the fact has always been both practice and bain in
programming, and nowhere more so than in scientific programming.  Who
wants to clutter up the clarity of code with a lot of rambling design
discussion?

Well, it often helps to capture that in some form for future
maintenance discussions, if only so that one doesn't step into a
pitfall with no warning.

The .Net development environment does offer some enticements to better
documentation.  It can capture a variety of kinds of comments from
within code as XML nodes and present them back through "Intellisense"
mechanisms within Visual Studio.  Also the "collapsing outline"
feature of the VS editor makes it easy to hide/display varying levels
of detail so even rambling documentation need not be a constant
irritant.

Unfortunately it's not terribly intuitive how all that stuff works or
is to be used.  For an introductory discussion, try this:

[MSDN - XML Documentation Tutorial]
http://msdn.microsoft.com/library/en-us/csref/html/vcwlkxmldocumentationtutorial.asp

Both top-down and bottom-up programmers can benefit from this "side
channel" approach to managing in-line documentation.

8.  The burden of large datasets

The era of the terabyte dataset is upon us, as Microsoft has been
promoting for some time now:

[MSDN - Rosetta Genomics 10-Terabyte Human Genome Database]
http://www.microsoft.com/sql/techinfo/administration/2000/rosetta.asp

As we are entitled to expect, the .Net programming framework is at
least forward looking enough to contemplate 64-bit integers as a base
type.  No such native support for quadruple precision (128-bit)
floating point data yet, but enough address space to support really
preposterous array sizes.

Of course real proficiency in handling large datasets well will
require redoing the file system infrastructure.  FAT16 became FAT32,
but don't hold your breath for FAT64.  For some previews of what
changes "Whidbey" and "Longhorn" will bring to the file handling:

['Whidbey' Paving Path for Microsoft's Longhorn]
http://www.internetnews.com/dev-news/article.php/3308261

"It brings a level of integration between the toolset and the database
we've never had before," agreed Microsoft's Bixhorn. "In Whidbey,
because SQL Server [Microsoft's database application] integrates the
CLR into its core database engine, developers can write stored
procedures and functions in the languages they already know."

10.  In praise of the command line

While Windows is almost synonymous with a generation of programmers
who don't know anything about command line arguments, much less
makefiles and the rest of the dinosaurs' development environment,
these topics have never really left the world of production jobs and
esp. for large scale batch.

The nice thing is that Microsoft gives the command-line versions of
.Net SDK tools away for free:

[Microsoft .Net Framework Developer Center - Downloads]
http://msdn.microsoft.com/netframework/downloads/

For those with a micro-budget or just an affinity for doing things the
old-fashioned way, Microsoft has been generous.  I must admit to being
spoiled, though, esp. when it comes to debugging, by the Visual Studio
IDE.

But even so most of the code I write is either console-based or has no
UI to speak of (say an Excel VBA routine, which can just get invoked
from a spreadsheet cell and need not "know" anything about how its
arguments are input).  In this respect I feel quite at home with the
.Net framework.

* * * * * * * * * * * * * * * * * *

Nikolas-ga, I'd like to thank you for posting your Question.  It
challenged me to think about many things, a few of which I hope I
managed to capture in this brief discussion.  Feel free to post some
Requests for Clarification to extend the dialog.

regards, mathtalk-ga