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

Multiprocess utilization #8

Open
mirth opened this issue Jan 15, 2019 · 7 comments
Open

Multiprocess utilization #8

mirth opened this issue Jan 15, 2019 · 7 comments

Comments

@mirth
Copy link

mirth commented Jan 15, 2019

It seems that adding more cores doesn't improve speed proportionally. Why is that?

@xgfs
Copy link
Owner

xgfs commented Jan 15, 2019

Are you sure you add cores rather than threads? What is the size of the graph you are trying to process? Most likely it's a memory issue.

@mirth
Copy link
Author

mirth commented Jan 16, 2019

I increase threads parameter while running on 64 core machine.

@xgfs
Copy link
Owner

xgfs commented Jan 17, 2019

If the size of the graph is really large, there might still be memory issues, especially in NUMA architectures. Can you (roughly) specify the size of the graph, and memory system used?

@mirth
Copy link
Author

mirth commented Jan 18, 2019

Sorry for not starting with numbers first.

./deepwalk -input in.bcsr -output out.model -threads 64 -dim 300 -nwalks 1000 -walklen 5 -window 3 -seed 4242 -verbose 2
nv: 747556, ne: 861549483
PR estimate complete
Using vectorized operations
Constructing HSM tree...
Done! Average code size: 20.7494
lr 0.000002, Progress 100.00%
Calculations took 8225.28 s to run

./deepwalk -input in.bcsr -output out.model -threads 8 -dim 300 -nwalks 1000 -walklen 5 -window 3 -seed 4242 -verbose 2
nv: 747556, ne: 861549483
PR estimate complete
Using vectorized operations
Constructing HSM tree...
Done! Average code size: 20.7604
lr 0.000002, Progress 100.00%
Calculations took 12681.46 s to run

I ran it on 64 cores & 256Gb mem ec2 instance. The graph bcsr file is 3.3Gb. The process consumes 5.5Gb of memory while runnnig.

@xgfs
Copy link
Owner

xgfs commented Jan 20, 2019

From this limited information my most probably cause is memory access time. There is single DRAM contoller fetching graph (and embedding) parts from the memory, causing a bottleneck. This is probably not solvable unless you change the algorithm. If you are okay with higher memory consumption, you can consider an implementation that caches random walks in the memory.

On completely different issue, parameters you use seem quite a bit off. Why are you chaning the defaults?

@mirth
Copy link
Author

mirth commented Jan 21, 2019

You mean -nwalks 1000 -walklen 5 -window 3? I just playing with parameters to see how it behaves.

@xgfs
Copy link
Owner

xgfs commented Jan 23, 2019

If you want to see where the problem comes from, I would recommend running the process under GNU perf (tutorial here http://www.brendangregg.com/perf.html). I would expect that the running time is dominated with the memory access.

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

No branches or pull requests

2 participants