On Tue, 22 Aug 2006, Ed Hill wrote:
But seriously, I've read of efforts to standardize (within the official
ISO documents) the linking conventions so that its easier to call C
routines from Fortran and vice versa. Unfortunately, these proposals
were rejected during the last couple of Fortran st
On Tue, 2006-08-22 at 00:59 -0400, Robert G. Brown wrote:
>
> Perhaps in another decade they'll actually meet somewhere, have a
> drink together, and in a night of illicit love spawn a new language
> called Cortran, or perhaps fortraC, that groks both printf and
> hollerith, that has a binary expo
On Tue, 22 Aug 2006, Joe Landman wrote:
All OO (and GSL is OO in its interface) really want you to go through
their accessors. Basically where I got stuck was that I had to write
the retrieval dereferencer for a Perl object in C, and then store that
in GSL. Thought I could do that quickly, 1/2
Robert G. Brown wrote:
> On Mon, 21 Aug 2006, Joe Landman wrote:
>
>> I took a simple GSL program I used to introduce students to GSL, that
>> was a modified example from one of the GSL example files. Basically a
>> little Hooke's law bit to use as input to an LU solver. Really short
>> GSL pr
On Mon, 21 Aug 2006, Ed Hill wrote:
I want to be able to write codes that can make use of the vast existing
C and C++ libraries for, say, I/O or computational geometry or "systems"
type programming while simultaneously using existing Fortran routines
for building and integrating big systems of e
On Mon, 21 Aug 2006, Joe Landman wrote:
I took a simple GSL program I used to introduce students to GSL, that
was a modified example from one of the GSL example files. Basically a
little Hooke's law bit to use as input to an LU solver. Really short
GSL program.
Joe,
Since you clearly have t
On Sun, 2006-08-20 at 23:50 -0400, Robert G. Brown wrote:
> On Mon, 21 Aug 2006, Jonathan Ennis-King wrote:
>
> > The other option is the Unix-like strategy suggested by rgb, where for
> > example the computational part is completely written in C, and then the
> > pre and post-processing which be
Robert G. Brown wrote:
>> Obviously this is a trivial example, but if you create a reasonable set
>> of API's that you can express as we have indicated, even pass function
>> prototypes in using a header file, and a little config stuff at the
>> front end to give paths to libraries, this is not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> My specific question was whether anyone out there was running parallel
>> codes either written completely in Java, or with Java wrappering some
>> big numerical library for the hard part. Are there any additional issues
>> with parallel performance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
To give additional context, the choice of language is partly driven by
the desire to make the code open source (eventually) and usable by other
scientists (who are not exclusively programmers). This consideration
rules out the arcane or new-fangled. My
On Mon, 21 Aug 2006, Jonathan Ennis-King wrote:
One way to alleviate the performance hit is of course to use a 90% Java
strategy, where the computationally intensive 10% (here, parallel sparse
matrix inversion) is handled in C.
It's the mixed language part that worries me with Java, especially i
On Sun, 20 Aug 2006, Joe Landman wrote:
Robert G. Brown wrote:
[...]
Java, octave, matlab, python, perl etc. are MUCH WORSE in this regard.
All require NONTRIVIAL encapsulation of the library into the interactive
environment. I have never done an actual encapsulation into any of
Cant spe
Joe Landman wrote:
> I take a pragmatic view. If a language is well suited for a task, I
> think it makes sense to use it.
I agree 110%. I think we just differ on the breadth of task for which,
for example, Perl is appropriate.
> I don't advocate against Fortran. It is a great language, very us
Geoff Jacobs wrote:
> Biased? Perhaps.
>
> I think the compressed syntax as well as the broad semantics, which are
> a benefit to the implementer, really hamper ongoing maintenance of
> software written in Perl.
To avoid going into a language war, will basically leave this comment
with one not
Robert G. Brown wrote:
[...]
> Java, octave, matlab, python, perl etc. are MUCH WORSE in this regard.
> All require NONTRIVIAL encapsulation of the library into the interactive
> environment. I have never done an actual encapsulation into any of
Cant speak to Octave/Java/Matlab. Python and P
Jim Lux wrote:
> At 06:08 AM 8/20/2006, Joe Landman wrote:
[...]
>> Hey ... I like that +/vector is a sum reduction over a variable named
>> vector, and it can do it on the outermost index.
>
> But you need that special APL keyboard with the greek letters...
They weren't greek so much as ...
Joe Landman wrote:
>
> Geoff Jacobs wrote:
>
>> *throws on his scalliwag hat*
>> And also many inappropriate languages, such as Intercal, APL, BrainF***,
>> or even Perl when you're on a caffeine buzz.
>> *removes hat*
>
> Hey ... I like that +/vector is a sum reduction over a variable named
> v
On Sun, 20 Aug 2006, Joe Landman wrote:
Jonathan:
Jonathan Ennis-King wrote:
Does anyone have experience writing parallel Java code (using MPI) with
calls to C libraries which also use MPI? Is this possible/sensible? Is
there a big performance hit relative to doing the same in C++?
Unless al
At 06:08 AM 8/20/2006, Joe Landman wrote:
Geoff Jacobs wrote:
> *throws on his scalliwag hat*
> And also many inappropriate languages, such as Intercal, APL, BrainF***,
> or even Perl when you're on a caffeine buzz.
> *removes hat*
Hey ... I like that +/vector is a sum reduction over a variab
Geoff Jacobs wrote:
> *throws on his scalliwag hat*
> And also many inappropriate languages, such as Intercal, APL, BrainF***,
> or even Perl when you're on a caffeine buzz.
> *removes hat*
Hey ... I like that +/vector is a sum reduction over a variable named
vector, and it can do it on the out
Jonathan:
Jonathan Ennis-King wrote:
> Does anyone have experience writing parallel Java code (using MPI) with
> calls to C libraries which also use MPI? Is this possible/sensible? Is
> there a big performance hit relative to doing the same in C++?
Unless all of the important optimizable calculat
Andrew Piskorski wrote:
> On Thu, Aug 17, 2006 at 04:56:10PM +1000, Jonathan Ennis-King wrote:
>
>> I'm considering writing some parallel code to do fluid flow in porous
>> media, the heart of which is solving systems of sparse linear equations.
>> There are some good libraries in C which provide
On Thu, Aug 17, 2006 at 04:56:10PM +1000, Jonathan Ennis-King wrote:
> I'm considering writing some parallel code to do fluid flow in porous
> media, the heart of which is solving systems of sparse linear equations.
> There are some good libraries in C which provide the parallel solver
> (e.g. PET
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Does anyone have experience writing parallel Java code (using MPI) with
calls to C libraries which also use MPI? Is this possible/sensible? Is
there a big performance hit relative to doing the same in C++?
I'm considering writing some parallel code to
24 matches
Mail list logo
