ChanServ changed the topic of #mlpack to: "mlpack: a fast, flexible machine learning library :: We don't always respond instantly, but we will respond; please be patient :: Logs at http://www.mlpack.org/irc/
ib07 has joined #mlpack
ib07 has quit [Client Quit]
< _slack_mlpack_19>
Hi, i am trying to build mlpack from source(main branch in github). Bt while building the mlpack_test, it is consuming a lot of memory(around 5gb) and time.
< _slack_mlpack_19>
System config: ubuntu 20.04, i5 8th gen, 8gb ram and 16gb swap
< AvikantSrivasta7>
Use the option 'make j1' to build it one core
< _slack_mlpack_19>
Its consuming same amount of memory even after using j1
ImQ009 has joined #mlpack
< jonpsy[m]>
Hey, is using stl algorithms like ```std::generate``` or ```std:fill``` more cache friendly than raw loops?
< AyushSingh[m]>
(edited) ... looking for its ... => ... looking forward to its ...
< turska79Gitter[m>
@zoq Thank you
Shashank has joined #mlpack
Shashank has quit [Client Quit]
< rcurtin[m]1>
finally got through to the GT group that hosts dealgood (one of the build servers) and managed to get a time set up to go in and fight with it to get it back online... only took a year+ 😃
< shrit[m]>
ryan: great news
< shrit[m]>
Hope that the issue with the server is not going to be complicated to resolve
< shrit[m]>
probably booting issue
< shrit[m]>
or out of power
< rcurtin[m]1>
I know what the issue is---it has a connected Apple FastRAID that has died
< rcurtin[m]1>
but the FastRAID doesn't actually matter
< rcurtin[m]1>
so I'm just going to disconnect the FastRAID and get it running again
< rcurtin[m]1>
in fact the FastRAID was never actually hooked up to the machine even when we built it in 2010...
< shrit[m]>
Are you able to ssh to it?
< shrit[m]>
I mean what make you sure that it is related to FastRAID?
< rcurtin[m]1>
no, it's not booting right now; I think it refuses to boot because the FastRAID is throwing an error
< rcurtin[m]1>
I managed to get someone to physically look at the system a year ago and that's what they said they were seeing as BIOS messages
< shrit[m]>
I see, it was possible for him to do the fix right?
< rcurtin[m]1>
he said he didn't have time and had to focus on other things
< rcurtin[m]1>
it'll be easy for me to go in and fight with it; it's right down the street
< rcurtin[m]1>
like a 10 minute walk
< jonpsy[m]>
hey rcurtin
< jonpsy[m]>
remember that grammar fix PR I made? can we merge it directly please? I've opened another PR for optimizing NSGA2 (I've tagged you as well). Good day!
< rcurtin[m]1>
sure, I will take a look when I have a chance 👍️
< jonpsy[m]>
yeah and one more thing..
< jonpsy[m]>
the CI is telling me to update History.MD, but I've seen other grammar fix PR not doing it and still passing checks. Am I missing something? thanks !
< rcurtin[m]1>
can you link to another grammar fix PR where it passes the checks?
< jonpsy[m]>
Ah, my bad. I saw madhavshah's PR merged, so I thought it passed the checks
< rcurtin[m]1>
personally I don't mind ignoring the history check for something as simple as a tiny grammar fix
< jonpsy[m]>
+1 on that. Very well, see you on my Improved NSGA2 PR :D
< shrit[m]>
rcurtin: I fixed the same seed for random number generator. I expected to have the same analysis of the tree
< shrit[m]>
But the number are different in both trees
< jjb[m]>
Not quite deterministic 😢
< zoq>
shrit[m]: Is that on the same system?
< zoq>
shrit[m]: It's not guaranteed that you get the same random numbers across systems using the same seed.
< zoq>
shrit[m]: Just noted it's not the same armadillo version so I guess it's not the same system.
< shrit[m]>
It is running on the same system
< shrit[m]>
but one is statically linked, and transfered
< shrit[m]>
while the other is locally build on viking
< zoq>
Do you generate the dataset randomly as well?
< shrit[m]>
I fixed the same seed for both case, therefore I think that the series of the dataset is random but it should be the same right?
< shrit[m]>
and if it is the same, the output here should be the same
< zoq>
I would either use a static dataset or check if the generated dataset is the same, just to be sure.
< shrit[m]>
the issue is that the dataset is 5*100
< shrit[m]>
so writing that manually is an issue.
< shrit[m]>
I will try to print he dataset
< zoq>
You could generate it once save it and load it back in?
< shrit[m]>
good idea
< shrit[m]>
I will try to execute this time on my RPI instead of transferring to viking
< shrit[m]>
and compare with the viking dynamic linked library
< shrit[m]>
I see now what is happening
< shrit[m]>
there is the querySet that is randomly generated
< shrit[m]>
but they should be using the same seed right?
< shrit[m]>
I will just print out everything and see what happens
< shrit[m]>
Just to note: I executed each one on a different machine, neither the dataset or the queryset look similar
< shrit[m]>
In this case, I have to send the binaries to viking to compare them
< rcurtin[m]1>
you might be better off just computing a random dataset and saving it to CSV, then adapting the test to load the data from CSV
< shrit[m]>
Totally agreed,
travis-ci has joined #mlpack
< travis-ci>
mlpack/ensmallen#1148 (2.16.1 - d3b6f67 : Ryan Curtin): The build passed.