Hi:

I have the following type array:

TYPE :: LIN
INTEGER :: I
REAL*8 :: R
END TYPE LIN

TYPE(LIN) T(100)

Question is: is T array continurously stored? or by a dynamical link?

I raise this question 'cause I want a fast locating of the type array. Thanks for any help!

...
Question is: is T array continurously stored? or by a dynamical link?

Suppose I say that I believe the array is allocated as a contiguous block of memory.

But you must realize that I could be wrong. What If I am right? What if I am wrong?

Maybe it's different for different compilers. Suppose I have, somehow, performed an experiment that makes me come to a particular conclusion. Can we always trust our compiler to do the "right" thing? How do we know that your compiler behaves the same as mine? What if you carefully craft the program for optimal performance on a particular system and then you have to move to another system? Can you guarantee that it's still optimal? How?

...I want a fast locating of the type array....

Well, how fast is fast enough?

What if the array of derived types is not fast enough for some reason? What would you do? Maybe make two different arrays , one for the integers and one for the double precision variables (like people did in the olden days before Fortran 90), right?

How can you tell which is faster?

Well, maybe something like...

Make a test program that uses the array of derived types to do something significant (whatever your program is going to do with the array) millions of times or billions of times. Experiment until you can easily estimate the running time of the program. For example, make it so that the program runs for something like 10 seconds.


Then make a test program that performs the same operations but uses two different arrays.


Compare execution times.



Some considerations:

Examine your compiler options to see whether there is any way to tell it to optimize for speed. Compare run times for each method with and without optimization. Is there any reason not to tell the compiler to optimize for speed?


If performance were not an issue is there any reason that you would prefer a program with an array of derived types over a program with two separate arrays?


Is there any difference in the performance of the two methods? If your preferred method is slower than the other, is there enough difference in performance to affect your decision on which one to use?


How can you tell how much time is used for array access compared with whatever processing you are doing on the elements? (Maybe a "dummy" loop or nested loops that don't do much other than access the elements.) Are there any preventable bottlenecks in your program that are as significant or, maybe, more significant than array access?


Regards,

Dave

Thanks a lot! I figured out that they are continuously stored.


However, there is another question: for the above type, I found that the memory for a single type takes 16 Bytes, and it seems that FORTRAN90 automatically expanded the memory of the smaller variable according to the largest variable inside the type. Is there any way to avoid this? (I mean to take just 8+4 Bytes for the above type). Thanks a lot!

...it seems that FORTRAN90...
It is implementation-dependent.

Fortran compilers typically perform alignment of variables within derived types that makes for most time-efficient access. There may be compiler switches that tell the compiler to optimize for space rather than time. Consult your compiler documentation.

Regards,

Dave

hii guys,
can anybody help me with a problem in my fortran programming..
basically i use fortran77...in which i have recently wrtten a large code...
It was running properly earlier for all combinations of cycles and steps...but nw it works only for smaller no. of cycles and steps...for larger ones..it takes the run command,runs for about an hr. or two giving sme output properly but then it suddenly stops with the message-----SEGMENTATION FAULT....and the outfile remains incomplete...
if anybody knws the solution...kindly help me with the same..

...i have recently wrtten a large code...
It was running properly...but nw...

Is this some kind of simulation program?

Are you running a test case with deterministic input or with randomly generated events or what?

What changed from the time when it ran properly and now? Different input? Program changes? Different compiler and/or different operating system and/or different platform? Or what?


if anybody knws the solution...kindly help me with the same..
One possible cause of a "segmentation fault" is a program attempting to access an illegal memory location, as happens when a program tries to write beyond the end of an array.

The result is called "undefined behavior."

There are other kinds of bugs that can cause inconsistent results due to undefined behavior.


Maybe "undefined behavior" in your program is causing the problem and maybe not.

However...

You should note that it is not absolutely guaranteed that a program will crash when it does something illegal.

That is, sometimes it will seem to run normally.

Sometimes it will appear to run normally but will give incorrect or inconsistent results.

Sometimes it will crash silently. It might just quit prematurely with no information to the user.

Sometimes it will crash with a "segmentation fault" error message.

Sometimes---well, just about anything. Undefined is undefined.


if anybody knws the solution..

The solution is to remove the bug(s) from the program.


Regards,

Dave

hi dave,
thanks for ur reply...first i would like to tell u that the program ran properly earlier for all combinnations of cycles and steps so the syntax bugs are definitely not there...and since then i have neither changed the program nor the input which is fixed...
i didnt understand what u mean by undefined behaviour....what can be the possible causes for such behaviour...and what is the solution for this....
i further didnt get what bug removal u talked about...becoz the program is successfully compiled...infact even runs for 2 out of the 3 hrs. for which it should ideally run...
if possible please give me a clearer picture of ur suggestions..
regards
mohs

...clearer picture...

As I mentioned, one thing that can cause undefined behavior is a program trying to write beyond the end of an array. This isn't the only thing, but it's a common problem.

Suppose you declare an array with 100 elements and you try to write to element number 101? What if you try to write to element 0? All I can say is that I don't know. The result is undefined.


It might just happen that nothing Bad happens (or at least nothing obviously Bad). It might cause the value of some other variable to be overwritten with unintended data, and that might cause some bad effect later on in the program. That's what I meant by undefined behavior. In general, you can't prove a program is correct by testing, since undefined behavior may cause different (bad) things to happen under different circumstances (like what sequence of program operations have been executed before a particular function).

That's why I wanted you to tell a little about your program. If it is some kind of simulation (or other program) with some kind of randomized input stuff, then undefined behavior can arise after certain inputs but not others. If you have a totally deterministic system with exactly the same (non-random) inputs as before and you have made absolutely no changes to the program and the results are different, then undefined behavior is still the prime suspect. I know it's hard to imagine, but that's my experience.

Now, there may be other things that cause segmentation faults, but for starters you can try the following:

Look at your code. See if there any places where an expression that calculates an array index might give values outside the ranges of an array. Sometimes loop limits depend on variables that were erroneously used without being initialized. Sometimes things depend on user input (or something else that was obtained from some random value) that was not tested for proper values before being used in expressions. Stuff like that.


The only flat statement that I can make is that there is simply no way (no way) for me to tell you all the kinds of bugs that can cause programs to crash with segmentation errors (or anything else).

Sorry.


Regards,

Dave