Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Benchmark of ADT-based solvers against procedural ones #24

Open
milancurcic opened this issue Oct 17, 2015 · 2 comments
Open

Benchmark of ADT-based solvers against procedural ones #24

milancurcic opened this issue Oct 17, 2015 · 2 comments

Comments

@milancurcic
Copy link
Contributor

Exactly what the title says. I think it will be important to test and benchmark the performance of FOODiE's solvers against their equivalents written in a procedural style, essentially testing the efficiency of abstract data types and overloaded operators. The results will have to be satisfactory in order for FOODiE to be considered in HPC applications. I am not sure yet what satisfactory means in this case but I will think about it.

Comparing the performance of FOODiE between major Fortran compilers will be elucidating as well.

Please discuss. I will be happy to make some tests in the next few weeks.

@szaghi
Copy link
Member

szaghi commented Oct 17, 2015

You are reading into my mind... I have already started a non abstract Euler 1D to compare with the one already shiped with FOODiE.

After the apparently non exciting openmp benchmarks (indeed I made a mistake for measuring weak scaling, and strong one was not so bad) I started a procedural euler 1D test. I hope to upload it monday.

Thank you Milan for pointing it out!

@szaghi
Copy link
Member

szaghi commented Oct 19, 2015

Done. I have added the 1D Euler OpenMP-enabled test solved without FOODIE.

The results seem good

strong-scaling-comparison
weak-scaling-comparison

For details see the manuscript.

possible issue

@francescosalvadore let me conscious that my analysis could be "partial": for verifying if a code scales satisfactory the reference serial baseline code should be highly optimized (in particular I have to check is the compiler has been able to vectorize the baseline code). I have used for all codes (serial-FOODIE, OpenMP-FOODIE, serial-without-FOODIE and OpenMP-without-FOODIE) the same -O2 compiling flags (with gfortran 5.2.0) without taking care of the actual level of optimization the compiler produced. Maybe the serial codes are not well optimized, thus the scaling result so good... Anyway, this slightly affects my aim: I just want to prove that FOODIE does not destroy the scaling, not that this test scales good itself in an absolute meaning...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants