search

ruanjue / wtdbg2

Redbean: A fuzzy Bruijn graph approach to long noisy reads assembly
GNU General Public License v3.0
508 stars 93 forks source link

v2.4 is much slower than v2.3 with large ONT, SQ data #107

Closed macarima closed 5 years ago

macarima commented 5 years ago

I'm using wtdbg2 v2.3 and v2.4 for assembling ONT and PacBio data (pacbio sequel for 3Gb genome and promethion for 20Gb genome). I found v2.4 is much slower than v2.3, when I try to assemble large set of data. Especially for 20G genome. For counting kmer and showing kmer distribution, v2.3 took only 20 minutes for 3Gb genome and 2 hours for 20Gb genome. However with v2.4, about 2.5 hours for 3Gb genome and more than 3 or 4 days for 20Gb genome (not finished yet). For under 1Gb genome assembly, v2.4 was not so slow.

I used parameters like belows.

  1. PacBio : wtdbg2 -t 190 -x sq -g3g -p 20
  2. PromethION : wtdbg2 -t 240 -x ont -g20g -p 20 -e 2 -L 5000

Thank you for your work. It is the most useful assembler for ultra long reads.

ruanjue commented 5 years ago

I am a bit confused. Can you send the log message files to me (ruanjue AT gmail.com)? I will find what happened between v2.3 and v2.4.

macarima commented 5 years ago

I am a bit confused. Can you send the log message files to me (ruanjue AT gmail.com)? I will find what happened between v2.3 and v2.4.

Sure. And I fixed some in my previous comment. "v2.3 took only 20 minutes and v2.4 took about 2.5 hours".

I'll send you e-mail. Thank you.

ruanjue commented 5 years ago

I found a strange thing in the runtime, it is about the user time and sys time.

3g + v2.3
** PROC_STAT(0) **: real 4336.490 sec, user 169730.130 sec, sys 161616.530 sec, maxrss 66177888.0 kB, maxvsize 98551600.0 kB
3g + v2.4
** PROC_STAT(0) **: real 9429.484 sec, user 474856.780 sec, sys 416014.430 sec, maxrss 65585312.0 kB, maxvsize 81921844.0 kB

Usually, we will get much much less sys time than user time. Like in your 20g+v2.3, it looks nice.

** PROC_STAT(0) **: real 3674.795 sec, user 141354.400 sec, sys 6005.630 sec, maxrss 134105768.0 kB, maxvsize 174955480.0 kB

But in 20g + v2.4 (indexing the 1/5 part) 

** PROC_STAT(0) **: real 3380.174 sec, user 40148.690 sec, sys 38796.350 sec, maxrss 131008904.0 kB, maxvsize 170254396.0 kB

Could you test small genomes on other PowerPC, if the sys time still very big, I will try to find what's happened again.

Jue

macarima commented 5 years ago

I found a strange thing in the runtime, it is about the user time and sys time.

3g + v2.3
** PROC_STAT(0) **: real 4336.490 sec, user 169730.130 sec, sys 161616.530 sec, maxrss 66177888.0 kB, maxvsize 98551600.0 kB
3g + v2.4
** PROC_STAT(0) **: real 9429.484 sec, user 474856.780 sec, sys 416014.430 sec, maxrss 65585312.0 kB, maxvsize 81921844.0 kB

Usually, we will get much much less sys time than user time. Like in your 20g+v2.3, it looks nice.

** PROC_STAT(0) **: real 3674.795 sec, user 141354.400 sec, sys 6005.630 sec, maxrss 134105768.0 kB, maxvsize 174955480.0 kB

But in 20g + v2.4 (indexing the 1/5 part)

** PROC_STAT(0) **: real 3380.174 sec, user 40148.690 sec, sys 38796.350 sec, maxrss 131008904.0 kB, maxvsize 170254396.0 kB

Could you test small genomes on other PowerPC, if the sys time still very big, I will try to find what's happened again.

Jue

Ok, I'll try.

And as I told you in my e-mail, wtdbg v2.4 created twice as number of threads, as I demanded. That's the reason why v2.4 is slow, I think. I'll send you the screenshot.

Kim

macarima commented 5 years ago

These are screenshots what I told you from github.

Best,

Kim

This is the command what I used. 2019-05-11_13-29-52

And, system usage infomation using HTOP. 408 threads running. Red bar is for system. Green bar is for wtdbg. Too many threads often made this situation. 2019-05-11_13-28-54

      1. 오후 8:04, Jue Ruan notifications@github.com 작성:

I found a strange thing in the runtime, it is about the user time and sys time.

3g + v2.3 PROC_STAT(0) : real 4336.490 sec, user 169730.130 sec, sys 161616.530 sec, maxrss 66177888.0 kB, maxvsize 98551600.0 kB 3g + v2.4 PROC_STAT(0) : real 9429.484 sec, user 474856.780 sec, sys 416014.430 sec, maxrss 65585312.0 kB, maxvsize 81921844.0 kB Usually, we will get much much less sys time than user time. Like in your 20g+v2.3, it looks nice.

PROC_STAT(0) : real 3674.795 sec, user 141354.400 sec, sys 6005.630 sec, maxrss 134105768.0 kB, maxvsize 174955480.0 kB But in 20g + v2.4 (indexing the 1/5 part)

PROC_STAT(0) : real 3380.174 sec, user 40148.690 sec, sys 38796.350 sec, maxrss 131008904.0 kB, maxvsize 170254396.0 kB Could you test small genomes on other PowerPC, if the sys time still very big, I will try to find what's happened again.

Jue

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ruanjue/wtdbg2/issues/107#issuecomment-491250348, or mute the thread https://github.com/notifications/unsubscribe-auth/AGBML4ERTXLWTI3QJH4R7NTPUVJEBANCNFSM4HMA47IQ.

macarima commented 5 years ago

And These are from v2.3

2019-05-11_14-35-16 2019-05-11_14-35-32

Best, Kim

      1. 오후 1:40, Hui-su Kim macarima@gmail.com 작성:

These are screenshots what I told you from github.

Best,

Kim

This is the command what I used.

<2019-05-11_13-29-52.png> And, system usage infomation using HTOP. 408 threads running. Red bar is for system. Green bar is for wtdbg. Too many threads often made this situation. <2019-05-11_13-28-54.png> > 2019. 5. 10. 오후 8:04, Jue Ruan > 작성: > > I found a strange thing in the runtime, it is about the user time and sys time. > > 3g + v2.3 > ** PROC_STAT(0) **: real 4336.490 sec, user 169730.130 sec, sys 161616.530 sec, maxrss 66177888.0 kB, maxvsize 98551600.0 kB > 3g + v2.4 > ** PROC_STAT(0) **: real 9429.484 sec, user 474856.780 sec, sys 416014.430 sec, maxrss 65585312.0 kB, maxvsize 81921844.0 kB > Usually, we will get much much less sys time than user time. Like in your 20g+v2.3, it looks nice. > > ** PROC_STAT(0) **: real 3674.795 sec, user 141354.400 sec, sys 6005.630 sec, maxrss 134105768.0 kB, maxvsize 174955480.0 kB > But in 20g + v2.4 (indexing the 1/5 part) > > ** PROC_STAT(0) **: real 3380.174 sec, user 40148.690 sec, sys 38796.350 sec, maxrss 131008904.0 kB, maxvsize 170254396.0 kB > Could you test small genomes on other PowerPC, if the sys time still very big, I will try to find what's happened again. > > Jue > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub , or mute the thread . >
ruanjue commented 5 years ago

I cannot see the screenshots. However, I found the strange sys time on my PC too, will fix it.

Thanks, Jue

ruanjue commented 5 years ago

Please try again with https://github.com/ruanjue/wtdbg2/commit/cf42c29c40da23663d7d8f26b4a219c94d9140e9 . Reduced threads overload.

Jue

macarima commented 5 years ago

Please try again with cf42c29 . Reduced threads overload.

Jue

I added screenshots. And I'll try cf42c29. Thank you so much.

Kim

macarima commented 5 years ago

I tested 20G genome assembly again with cf42c29. And I got "user 18398799.160 sec, sys 1042618.270 sec". This is normal and better than v2.3 for speed, I think. Thank you.

Kim