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

[WIP] Expand 64-bit edge support #148

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

FreddieWitherden
Copy link

This is a first pass at updating the public API to support 64-bit edges.

Note that lots of things are still broken, and I have not yet get around to the Java stuff. Proper support for MPI will require switching to the big-count interfaces which might bump the required MPI version. Going forwards I suspect that 64-bit node support will be required too (I currently routinely partition graphs with ~1.4B vertices). But this will require more changes (redefine NodeID, ensure consistent use, update header definitions).

Feedback would be appreciated.

Copy link

@olesenm olesenm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor comments

@@ -8,12 +8,21 @@
#ifndef KAFFPA_INTERFACE_RYEEZ6WJ
#define KAFFPA_INTERFACE_RYEEZ6WJ

#include <stdint.h>
#include "kaHIP_config.h"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor, but perhaps this:

#include "kaHIP_config.h"

#ifdef __cplusplus
#include <cstdint>
extern "C"
{
#else
#include <stdint.h>
#endif

I'm always wary about including the C headers instead of C++ ones...

NodeID number_of_nodes = 0;
EdgeID number_of_edges = 0;

MPI_Datatype MNodeID = (sizeof(NodeID) == 4) ? MPI_INT : MPI_LONG_LONG;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not MPI_INT32_T and MPI_INT64T instead?

@FreddieWitherden
Copy link
Author

These issues should be resolved. On the MPI side some more work will be needed when NodeID's are used rather than the current hybrid of int/NodeID's. As such the MPI datatype for the node remains as MPI_INT.

@olesenm
Copy link

olesenm commented Apr 3, 2024

These issues should be resolved. On the MPI side some more work will be needed when NodeID's are used rather than the current hybrid of int/NodeID's. As such the MPI datatype for the node remains as MPI_INT.

What got my attention was the use of MPI_LONG_LONG instead of MPI_INT64_T or perhaps MPI_LONG.
May need to check if these map properly to the int64_t on various systems (OSX can be a problematic one if I remember correctly, not sure about mingw cross-compile)
Looks OK - next time I'll read the diff instead of the comment first...

@FreddieWitherden
Copy link
Author

What got my attention was the use of MPI_LONG_LONG instead of MPI_INT64_T or perhaps MPI_LONG.

I think long long is always 64-bit. A regular long, however, is 32-bit on 64-bit Windows and 64-bit everywhere else which can be something of a pain.

@FreddieWitherden
Copy link
Author

So I am not quite sure what to do on the Java side. I do not have a lot of familiarity with JNI and having the prototype change dynamically depending on how the library is compiled seems somewhat tricky. Does anyone have any suggestions here?

@schulzchristian
Copy link
Member

sorry for the delay. I will have a look and provide feedback, it will just take a little while longer.

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

Successfully merging this pull request may close these issues.

None yet

3 participants