5 ms·
A lot of the arguments in this post can simply be rebutted with basic abstractions. Things like "Dynamically allocating and deallocating ... 2D array" is easy i
by gravypod 9y ago
A lot of the arguments in this post can simply be rebutted with basic abstractions. Things like "Dynamically allocating and deallocating ... 2D array" is easy in C++. You could easily have someone define a MathArray<Type, Rows, Columns> class and turn this messy fortran code:
real, dimension(:,:), allocatable :: name_of_array
allocate(name_of_array(xdim, ydim))
Into something that looks like
auto *my_matrix = new MathArray<double, 10, 10>();
The code the author showed demonstrates a lack of understanding of C and C++. Even if you restrict it to C your matrix code should look something like this
typedef struct {
size_t rows, cols;
void values[];
} mat;
inline mat *matrix_make(size_t rows, size_t cols, size_t value_size) {
mat *m = malloc(sizeof(size_t) + sizeof(size_t) + (rows * cols * value_size));
m->rows = rows;
m->cols = cols;
memset(m->values , 0, rows * cols * value_size);
return m;
}
While that code may be complicated the physicists only need to see....
mat *matrix = matrix_make(10, 10, sizeof(double));
And if you'd really like you can hide the sizeof via a macro...
#define MATRIX_MAKE(r, c, type) matrix_make(r, c, sizeof(type))
For me "real, dimension(:,:), allocatable :: " is much more complicated than "matrix_make"
Many of the issues people see in the speed difference between Fortran and C code will likely be based on their misunderstanding of how Fortran actually does their data layout and a misunderstanding of how the computer hardware (and what you're describing to C) to do. This "Double array" that was defined would never be allowed in production code. The amount you'd be hitting the OS for even small allocations is crazy.
The arguments for Fortran, as far as I'm concerned, are:
1. We already know it
2. We're not going to get grant money to rewrite a library
3. We've built a bunch of computer clusters and have to justify what we spent (rather than buying 2 GPUs for your workstation)
4. We've all spent a lot of time learning how to use MPI that we're never getting back.
- rsfern 9y agoI think your 3. and 4. are phrased a bit dismissively, though I don't entirely disagree. Not every workload in scientific computing maps cleanly into the GPGPU paradigm. Though that's not really a compelling reason to use Fortran over C++ An additional reason I've heard (I don't personally use Fortran) for keeping Fortran around is that it's straightforward to convert Matlab prototype code into Fortran
- tmyklebu 9y agoYou're making a pretty big deal about trivial syntactic issues. > Into something that looks like > > auto *my_matrix = new MathArray<double, 10, 10>(); The dimensions here are a template parameter. They must be known at compile time. Also, if you go this route and you want to write a function that, say, adds two matrices, you get one copy of that function in your binary for every matrix size that occurs in your program. You also can't naturally interoperate with someone else's matrix code unless that someone else specifically wrote against your MathArray template class. > And if you'd really like you can hide the sizeof via a macro... > > #define MATRIX_MAKE(r, c, type) matrix_make(r, c, sizeof(type)) > > For me "real, dimension(:,:), allocatable :: " is much more complicated than "matrix_make" It looks uglier, but it's language syntax rather than custom code. Whoever is reading your code doesn't have to unpack a macro and then look into a function to figure out what you're doing. (And as a bonus, the Fortran user can index the matrix without mentioning that it's a 'double' matrix when he's indexing.) > Many of the issues people see in the speed difference between Fortran and C code will likely be based on their misunderstanding of how Fortran actually does their data layout and a misunderstanding of how the computer hardware (and what you're describing to C) to do. This "Double array" that was defined would never be allowed in production code. The amount you'd be hitting the OS for even small allocations is crazy. Which many issues are you thinking about? Idiomatic Fortran has an inherent advantage over idiomatic C in that better aliasing information is available to the compiler.
- antnisp 9y agoMPI is availabe for C too. It even had C++ bindings but there were deprecated since not even boost used them.
- sampo 9y ago> auto *my_matrix = new MathArray<double, 10, 10>(); In Fortran, one can choose the matrix size at runtime, though. But otherwise, great. Now if you just add slicing so that if we, say allocate(name_of_array(-1:5, 1:3)) and then say fill in the matrix by 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 then name_or_array(0:4:2,2:3) should return 9 11 13 16 18 20 and then we're talking. (Slicing should of course also work in higher dimensions than 2.)
- gravypod 9y agoIf you want to do make an implementation that supports runtime-specified matrix sizes you change your implementation from... auto *my_matrix = new MathArray<double, 10, 10>(); Into auto *my_matrix = new MathArray<double>(10, 10); Most programs don't need dynamically sized arrays (rows and columns) and as such it makes sense to also provide a template Row and Column width. By doing this you can likely implement matrix multiplication and addition as a constexpr (with some effort) and thus get.... 1. Compile time matrix evaluation 2. Vectorized multiplication/addition of matrices 3. Pipline-efficient code