[ssh123]

Recently I re-implement my C++ code in Java and realize that the Java execution is faster than the C++ one ! The code takes a gmsh .msh file and convert it to .dat Tecplot file and .vtk file (Paraview).

With JDK 8 my Java code took ~2.6 seconds, whereas the C++ version took:
~5 seconds (MinGW g++ 10.2 with -O3 optimization flag).
~2.8 seconds (MinGW g++ 4.9.2 with -O3 optimization flag).

Key point could be the performance of C++ vector and Java List interface.

Have you ever faced similar situation?

Edited: Looks like this is a bug of MinGW g++ 10.2. My C++ implementation is just slightly slower than Java although it's heavily object oriented.

Ps: I have posted my code to GitHub so that you can have better judgement.
C++: https://github.com/truongd8593/GmshToVtkAndTecplotCpp11
Java: https://github.com/truongd8593/MisaCFDJava

[piu58]

I ever found C++ much faster than Java. The most inhibiting thing is the usage of memory in Java.

[aerosayan]

C++ is fine. Coder needs to improve.


I didn't look through the whole code, but two major things stick out:

1. You use vector.push_back a lot, without reserving memory beforehand, so it has to do multiple memory re-allocations, which are extremely slow, and will happen thousands of time if hundreds of thousands of cells and faces are being read from the files, and into those vectors. READ THIS : https://stackoverflow.com/questions/...ck-memory-wise READ THIS : https://stackoverflow.com/questions/...located-vector
2. You use std::endl so much, it's definitely trashing your performance. READ THIS (kindly ask any questions here, not in that thread) : share your best C/C++ trick/tips

I didn't look more, but your C++ code is so heavily object oriented, it hurts. OOP hurts performance if used too much, and without care. Although, I use OOP too, it's to organize my code. Those getX(), setX(), and other functions hurt performance if you want extremely fast code.


Learn Data Oriented Design and learn the pitfalls of OOP : https://youtu.be/x1xkb7Cfo6w https://youtu.be/g1TsP60z2OQ


Those getX, getY functions should be written as free functions, not hide them inside objects : i.e write something like getX(Point3D& p) then pass your objects to this function, and get the x values. If you want to study more, here's one excellent talk : https://youtu.be/WLDT1lDOsb4 <- although this might confuse you in the beginning.




There's a lot more problematic code here, but I don't want to write everything here at once. I will update the other thread I created on sharing best C/C++ tricks, and share some things which C++ programmers should know about performance, but it may take some time.


C++ is tough. It will take you a few years *on your own* to find and fix every performance mistake. I have spent that much time doing that, and have just begun to understand how to extract highest performance from C++. I will share more in the other thread when I have time.


Best of luck.

[aerosayan]

Basically, start hating modern C++ features, and write C++ code more like C, to get more performance.


Orthodox C++ is a good start (but I don't agree with using printf for everything, as cin and cout are good enough ) : https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b


If you don't start hating modern C++, your code will become like this (and it already has, to some extent) MUST READ : https://archive.md/2014.04.28-125041...ry/design.html


Here's why it's good to keep C++ code C-imple : https://youtu.be/lTXHOOwfTAo


There's no shortcut. Everyone teaches C++ wrong. You have years of bad practices to unlearn. It will take at least 3 months to understand most of it.



I'm a C++ coder who hates modern C++, so I get extremely good performance.

[ssh123]

I know what you mean. I have a C++ code written by one of my former lecturer in my university. The code implements Discrete Duality Finite Volume (DDFV) for Stokes equation. He only uses kind of

double * volume;
double** solution;
int* cellId;

which makes the code looks like C code. And great performance!

[aerosayan]

exactly. where there are abstractions, there's potential for performance degradation to be hidden behind the abstractions.

[aerosayan]

Originally Posted by ssh123

which makes the code looks like C code. And great performance!

Here's a C based CFD code for plasma and reactive flows, that I'm currently studying : https://github.com/bernardparent/CFDWARP


Since it's in C, it's written in a way, high performance C++ coders could learn from.

[aerosayan]

Dear ssh123,


I saw that a LOT of your code is OOP based, and I mentioned that OOP can be bad for performance.


Incidentally, I observed the same thing in my code.


I was calculating residuals using the following formula, and I observed that it wasn't being vectorized. That's because there's two levels of OOP here. first object lc, then object flux11_'s [] operator call.

    // Calculate residuals
    #pragma omp simd
    for(i=0; i<ncells*4; ++i)
    {
        r_[i] = lc.flux11_[i]*lc.sareas1_[i] + lc.flux21_[i]*lc.sareas2_[i]
        +       lc.flux31_[i]*lc.sareas3_[i] + lc.flux41_[i]*lc.sareas4_[i];
    }

So, I optimized the code, by using simple restricted pointers like :

    // Restricted pointers
    double * __restrict__ fx11 = lc.flux11_._head; // <- notice 2 levels of OOP

    // ...
    // ...
 

    // Calculate residuals
    #pragma omp simd
    for(i=0; i<ncells*4; ++i)
    {
        r[i] = fx11[i]*s1[i] + fx21[i]*s2[i] + fx31[i]*s3[i] + fx41[i]*s4[i];
    }

Now, this code gets vectorized, and the performance improves.


Hope this makes it clear.

[ssh123]

I double check my C++ code with previous g++ version (4.9.2, with -O3 optimization flag). Elapsed times is ~2.8 seconds. In total, the "modern" C++ version is slightly slower than Java version.

[arjun]

Originally Posted by ssh123

Have you ever faced similar situation?

No because I won;t consider Java for serious calculations and work.


PS: I am regretting writing the whole GUI in Java though. Thankfully it does not have to do the heavy work that solver does.

[ssh123]

Originally Posted by arjun

PS: I am regretting writing the whole GUI in Java though. Thankfully it does not have to do the heavy work that solver does.

I think Java is good for GUI programming. It's portable with minimal effort comparing to C++.

Originally Posted by arjun

No because I won;t consider Java for serious calculations and work.

The reason behind my preference of Java is the labor market in Vietnam where I was born. There are many jobs for Java programmers with better benefits compared to C++. Programming CFD code in Java will make me strong in Java Core.
Another reason which can be considered is IDEs. IntelliJ IDEA helps Java coders more productive than C++ IDEs as far as I know. All getters and setters in my Java version are generated automatically by IntelliJ IDEA, even the inner builders.

[arjun]

Originally Posted by ssh123

I think Java is good for GUI programming. It's portable with minimal effort comparing to C++.

If only if stops crashing when anything slightly bigger in size is given we can use it as GUI. Without data to handle it is good but unfortunately CFD means data.


Anything that is no stable is useless no matter how small efforts it takes to program it. It is very frustrating if your application keeps crashing.

[aerosayan]

Originally Posted by arjun

If only if stops crashing when anything slightly bigger in size is given we can use it as GUI. Without data to handle it is good but unfortunately CFD means data.


Anything that is no stable is useless no matter how small efforts it takes to program it. It is very frustrating if your application keeps crashing.

Legit issue. StarCCM+ also uses Java as their GUI, and I heard it can be slow sometimes. I don't know much about GUI programming, as I don't need it right now, but I would probably use Qt/GTK/wxWidgets for the GUI and an embedded OpenCascade system to handle the CAD rendering and stuff. FreeCAD also uses Qt+OpenCascade, it it works very well.

[arjun]

Originally Posted by aerosayan

Legit issue. StarCCM+ also uses Java as their GUI, and I heard it can be slow sometimes. I don't know much about GUI programming, as I don't need it right now, but I would probably use Qt/GTK/wxWidgets for the GUI and an embedded OpenCascade system to handle the CAD rendering and stuff. FreeCAD also uses Qt+OpenCascade, it it works very well.

A lots of CCM customers and CCM support engineers are annoyed by Java crashing. I know many of them, some of them are close friends.

Having said that, ccm does not pass heavy data to Java. C++ handles it and then send the minimum possible to Java. Its complicated framework. I personally avoided that because I do not want to have vtk in solver side but ccm has vtk in solver (c++) code exactly because of this issue. (C++ is the reason it does not crash post processing heavy data).

[naffrancois]

Sorry to spoil the original topic

Some time ago I started developing a GUI for our cfd code using Java, then left it aside. For rendering and visualization used vtk-java wrapper. I did not experience much unstability but true that I did not go beyond million elements meshes, are there still nowadays these memory-related crashes using java-vtk ?

Arjun, what do you mean when you say ccm implemented vtk in solver side ? These post-processing tasks should not they be fully decoupled from solver operations ? How do you handle rendering/viz in you application ?

[arjun]

Originally Posted by naffrancois

are there still nowadays these memory-related crashes using java-vtk ?

At least I got frustrated with them.

Originally Posted by naffrancois

Arjun, what do you mean when you say ccm implemented vtk in solver side ?

ccm is java on gui side and c++ on solver side. So the heavy post processing work is performed at solver side where vtk is used. GUI used to finally render it. Or in other words it does not use Java wrapper for vtk in java side.

My program does and having issues with memory.

Originally Posted by naffrancois

How do you handle rendering/viz in you application ?

Simple answer is that I do not. Solver side does not use any external library and this comes with benefit that now solver could be used anywhere.

So no vtk is linked and i leave the post processing to paraview.

However, the FD (finite difference solver) used GUI java for visualization and thats where the problems came with java memory.

[aerosayan]

Originally Posted by arjun

However, the FD (finite difference solver) used GUI java for visualization and thats where the problems came with java memory.

That seems important.


Writing an OpenGL based rendering system in C++ is somewhat difficult, but possible. I, and many others have done it before as a hobby project. To handle large meshes, after the data is streamlined to the GPU, OpenGL does a lot of optimizations to speedup the rendering process. One for example is called "backface culling" where the faces that aren't visible, will not be rendered. Another very important optimization is to use LOD (Level Of Detail) to speed up the rendering. You might have observed this in Paraview, when you rotate a big mesh, but while rotating, it shows a very coarse mesh. This is also seen in ANSYS, when you zoom out, the whole mesh is not being rendered. There are many such optimizations that are possible.


In six months and with some per-requisite knowledge of the OpenGL/Vulkan rendering system, it's possible to build a rendering system to handle millions of cells on screen : https://youtu.be/egOx4jMIaOg


Best of luck


EDIT : I forgot to mention that the LOD optimization is done by an experienced coder not OpenGL/Vulkan. Thought I should clear that up, as otherwise that might give a wrong impression and false promises of the features of OpenGL/Vulkan.

[arjun]

In java the problem seem to originate when one has to again and again allocate the momery for same variable. That is when the array size keep changing.

For example if i plot a vector plot and then do it again with say on different plane and do it few times, i increase the chances of crashing.


C++ and C suffer no such problems because here we can control this process. In java someone has great idea to let the language do it and not provide any control over it (at least i do not know if there is such thing).

[JBeilke]

Originally Posted by arjun

In java the problem seem to originate when one has to again and again allocate the momery for same variable. That is when the array size keep changing.

For example if i plot a vector plot and then do it again with say on different plane and do it few times, i increase the chances of crashing.


C++ and C suffer no such problems because here we can control this process. In java someone has great idea to let the language do it and not provide any control over it (at least i do not know if there is such thing).

Did you ever try an ArrayList instead of an normal Array in Java?

[sbaffini]

I think it would be useful/fun for this Forum to have a CFD Horror Stories section where all such experiences could be collected more organically