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

Is it possible enable multithreading in deepdream function? #34

Open
itsTeknas opened this issue Aug 9, 2015 · 6 comments
Open

Is it possible enable multithreading in deepdream function? #34

itsTeknas opened this issue Aug 9, 2015 · 6 comments

Comments

@itsTeknas
Copy link

I've noticed that the actual deepdream function that does the work actually runs on a single thread. So no matter how powerful multicore processor you got, it will only use a very small portion of it.
I am a newbie in this field, can someone tell if its possible to have a multithreaded function ?

I executed htop inside the compute container and i got this... notice only core 1 is used and others are idle.

  1  [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]     5  [                                                                     0.0%]
  2  [                                                                     0.0%]     6  [                                                                     0.0%]
  3  [                                                                     0.0%]     7  [                                                                     0.0%]
  4  [                                                                     0.0%]     8  [                                                                     0.0%]
  Mem[|||||||||||||||||||||||||||||||||||||||||||||||||             1140/2001MB]     Tasks: 7, 1 thr; 2 running
  Swp[|||||||||||||||||                                               103/460MB]     Load average: 1.17 1.06 0.87 
                                                                                     Uptime: 05:00:11

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
  528 root       20   0 1633M 1037M 42900 R 100. 51.8  0:42.06 python deepdream.py
  544 root       20   0 23020  3292  2632 R  0.7  0.2  0:00.01 htop
    1 root       20   0 17960     0     0 S  0.0  0.0  0:00.07 /bin/bash -c cd /opt/deepdream && ./process_images.sh 2>&1 > log.html
    6 root       20   0 17964     0     0 S  0.0  0.0  0:00.00 /bin/bash ./process_images.sh
    7 root       20   0 17980     0     0 S  0.0  0.0  0:00.00 /bin/bash ./process_images_once.sh
    9 root       20   0 17984  1916  1784 S  0.0  0.1  0:00.04 /bin/bash ./process_images_once.sh
  529 root       20   0 1633M 1037M 42900 S  0.0 51.8  0:00.00 python deepdream.py
  530 root       20   0 18168  3300  2844 S  0.0  0.2  0:00.09 bash





F1Help  F2Setup F3SearchF4FilterF5Tree  F6SortByF7Nice -F8Nice +F9Kill  F10Quit
@jontonsoup
Copy link

bump

@ghost
Copy link

ghost commented Aug 17, 2015

The deepdream process is inherently serialized. You have a stack of layers that the image gets fed through. The image goes into layer one, gets processed, then moves on to layer two, gets processed, gets moved to layer three, etc. You can't work on layers 1, 2, 3, and 4 simultaneously, as 4 requires the output from 3, 3 requires the output from 2, and so on. You could work on 4 different images concurrently if you wanted, but I'm not sure that is what you were getting at.

If you did want to work on 4 images concurrently, given that you have 4 cores, you would want multiprocessing, not multithreading, as CPU bound threading in python is gimped due to the GIL.

@jontonsoup
Copy link

Thanks-- I implemented multiprocessing already, the problem is I run into memory constraints so it's not great. I read about an alternate caffe build that enabled multi cores, but I haven't explored it yet.

On Mon, Aug 17, 2015 at 6:03 PM, ihaventkilledanybodysince1984
[email protected] wrote:

The deepdream process is inherently serialized. You have a stack of layers that the image gets fed through. The image goes into layer one, gets processed, then moves on to layer two, gets processed, gets moved to layer three, etc. You can't work on layers 1, 2, 3, and 4 simultaneously, as 4 requires the output from 3, 3 requires the output from 2, and so on. You could work on 4 different images concurrently if you wanted, but I'm not sure that is what you were getting at.

If you did want to work on 4 images concurrently, given that you have 4 cores, you would want multiprocessing, not multithreading, as CPU bound threading in python is gimped due to the GIL.

Reply to this email directly or view it on GitHub:
#34 (comment)

@StevenGann
Copy link

"Too bad there isn't some API that could distribute workload across GPU processors and do the same thing on CPUs depending on what was available"

I'm no expert, but I believe both CUDA and OpenCL are capable of this. I believe OpenCL can even manage it by default.

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

4 participants
@jontonsoup @itsTeknas @StevenGann and others