2

Quite often when I look at legacy Fortran code for linear algebra subroutines, I notice this:

Instead of working with a bunch of separate arrays, they will concatenate all their arrays into one big workspace array and use pointers to demarcate where a variable begins.

They even concatenate independent non-array variables into arrays. Are there benefits to doing this, and should I be doing this if I want to write optimized code?

GhostCat
  • 137,827
  • 25
  • 176
  • 248
Paradox
  • 1,935
  • 1
  • 18
  • 31
  • Thinking about it: interesting question, giving some food for thought. And you got a really nice answer, too. – GhostCat Jun 28 '17 at 12:20

2 Answers2

6

No, don't do that if you want to keep sane mind. This is a practise from 1960s-1980s when there was no dynamic allocation possible and they wanted only small number of working arrays in the argument list.

In old subroutines you had a long list of arguments and then one or two working arrays:

   call SUB(N1, N2, N3, M1, M2, M3, A, B, C, WRK, IWRK)

if you needed to pass 10 working arrays instead of one it would be too difficult to call it.

But in 21st century the most important thing is to keep your code readable and clear and only after that optimize it.

BTW having some quantities to close in memory can be even detrimental due to false sharing.

That does not mean you should fragment your memory too much, but it makes sense to keep stuff together when you will indeed access it sequentially. That's why structure of arrays are used instead of arrays of structures.

1

In general (independent of the programming language that is used): having "consecutive" blocks of well, anything is often helpful.

The operating system, or even the hardware might be able to benefit from having a single huge section in memory to deal with; compared to look at 50 or 100 different locations.

A good starter for such discussions would be this question for example.

But I agree 100% with the other answer: unless you get massive performance gains out of using such techniques, you should always prefer to write "clean" (aka readable) code. And that translates to avoiding such practices.

GhostCat
  • 137,827
  • 25
  • 176
  • 248