168k nodes, 4m edges, slow UI...

[phreakocious]

So I have this enormous graph, and an equally enormous system to process it on.. 40 cores, 192GB of RAM, Win7. Once the graph is loaded, the UI is almost unusable. What might be a Java garbage collection thread continuously consumes 100% of a single core, and the UI responds intermittently. I've played with a few things, and some GC tweaks seem to help somewhat, but it's still pretty rough.

Interestingly, this behavior is not as pronounced in linux, but parallel force atlas will not run in linux.

I am seeing this message periodically in the log file:
WARNING [org.netbeans.core.TimableEventQueue]: too much time in AWT thread org.netbeans.core.ui.sampler.SelfSamplerAction$InternalSampler@2b0114eb

Currently using these arguments:
default_options="--branding gephi -J-Xms120g -J-Xmx180g -J-XX:ParallelGCThreads=20 -J-XX:+UseConcMarkSweepGC -J-XX:+UseParNewGC -J-XX:SurvivorRatio=8 -J-XX:TargetSurvivorRatio=90 -J-XX:MaxTenuringThreshold=31 -J-XX:+AggressiveOpts -J-Dsun.java2d.noddraw=true -J-Dsun.awt.noerasebackground=true"

If anyone has any suggestions on how I might make this a bit more useful, I'd love to hear them.

[phreakocious]

Reducing the heap size to the least it needs to be to process the graph, and keeping the Data Lab view up instead of the Overview makes a major difference in this scenario. It looks like the updating of the graph is the biggest contributor to the UI slowness.

[mbastian]

You have quite a beast machine. But you'll need a good GPU for large graph visualization as well. Like one of this expensive Nvidia cards What is really killing it is drawing the edges I think, as usual. I've always turned off the edges drawing (or turned them on time to time only) for the graph size and it seems to work quite good.

What is happening is that the OpenGL thread is actually running in the same thread as the UI. The version of JOGL (1.1) we use works like this so if the visualization is struggling the UI will too. Hopefully this is not the case in JOGL 2.0, which our new visualization engine will be based on.

Thanks for the GC arguments, I think that should be useful to others as well.

[seinecle]

My two cents: I've experimented that ForceAtlas 2 is actually quicker than Parallel Force Atlas? At least when PFA is in CPU mode with 7 threads, not GPU (if that's indeed confirmed, it may be because the implementation details of Force Atlas 2 have been fine tuned.)

The point is, Force Atlas 2 runs on Linux, and you were saying above that it could be interesting for you bc you experience better performance on Linux.

Best,

Clement

[pbittner]

Clement is right: Force Atlas 2 is faster than Parallel Force Atlas (CPU or GPU) except for graphs of less than around 5000 nodes (due to the overhead of the Barnes Hut implementation). I have attached a graph of a benchmark that I have done to compare the performance of PFA with FA and FA2 that shows this.

I am currently working on a GPU implementation of Force Atlas 2 (in green on the graph) that is able to do 1 iteration of FA2 on a graph of 1 million nodes in about 3 seconds instead of 25 seconds for Gephi's implementation (CPU: i7 quad core, GPU: mid-range Geforce GT 540m). But for now, Force Atlas 2 is definitely the best fit to layout very large graphs!

[phreakocious]

Very cool, thanks for that information.

pbittner, I have been wanting to see the source for PFA (especially the GPU bits).. Any chance that is available to look at?

[pbittner]

The source code of PFA is available in the file cudaForceAtlas.cu that you can get there: https://github.com/paulantoineb/hpcgrap ... cGraphCuda

[phreakocious]

In case anyone's curious what this looks like when running:

[seinecle]

Does it mean the algo runs on 81 threads on the GPU?

[phreakocious]

This is Force Atlas 2 running 80 threads. Unfortunately, I don't have any crazy GPUs around to play with. For what it's worth, PFA doesn't scale quite so well. If there are too many threads, Gephi will crash hard with no stack trace (presumably the native libraries).