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/
< abernauer[m]>
Ok I should have the bindings built in the morning my Armadillo version is outdated.
BlakJak888 has joined #mlpack
< BlakJak888>
I am trying to compile the LSTM_STOCK_PREDICTION example but I am facing an error on Visual Studio 2019. The error is "C1060 compiler is out of heap space". I have succesfully compiled the MNIST Digit example so I do not believe it is my setup problem. Has anyone come across this error before? Any advice?
OmarWagih1Gitter has quit [Ping timeout: 244 seconds]
OmarWagih1Gitter has joined #mlpack
SakshamRastogiG4 has quit [Ping timeout: 244 seconds]
SakshamRastogiG4 has joined #mlpack
BlakJak888 has quit [Remote host closed the connection]
ImQ009 has joined #mlpack
d1 has quit [Ping timeout: 272 seconds]
d1 has joined #mlpack
< shrit[m]>
You can try to add to the compiler options `/Zm200` to resolve this error
< BlakJak888>
@shrit That was the first thing I tried. Actually used /Zm2000 - same error. I have since narrowed it down to a few lines of code that are generating the error.
< BlakJak888>
This code gives an error:
< BlakJak888>
if (bTrain || bLoadAndTrain){// RNN regression model.RNN<MeanSquaredError<>, HeInitialization> model(rho);if (bLoadAndTrain){// The model will be trained further.//std::cout << "Loading and further training model..." << std::endl;data::Load(modelFile, "LSTMMulti", model);}}
< BlakJak888>
Commenting out data::Load(modelFile, "LSTMMulti", model); causes the code to compile successfully
< BlakJak888>
However
radioactive11 has joined #mlpack
< BlakJak888>
... actually no however
< BlakJak888>
It definitely seems that the offending line of code is the data::Load()
radioactive11 has quit [Remote host closed the connection]
< BlakJak888>
In fact when I put back the full set of code for the example I had to comment out the 2 places in the code where the software tries to load the "LSTMMulti" file type. Leaving the "data::Save" for the "LSTMMulti" seemed to compile OK.
< BlakJak888>
Could it be a problem with boost::serialization ?
< BlakJak888>
I am using boost_1_74_0
< BlakJak888>
Going back to 1_73_0 seemed to make no difference. Here are the compiler error lines:
< BlakJak888>
D:\sdk\boost_1_73_0\boost\mpl\bind.hpp(539,1): fatal error C1060: compiler is out of heap space1> The command exited with code 2.1> Done executing task "CL" -- FAILED.1>Done building target "ClCompile" in project "StockPriceLSTM.vcxproj" -- FAILED.1>1>Done building project "StockPriceLSTM.vcxproj" -- FAILED.1>1>Build FAILED.
< BlakJak888>
The error is exactly the same with 1_74_0
hyyyyoui has joined #mlpack
< hyyyyoui>
Hi
< hyyyyoui>
I had a doubt in building mlpack
< hyyyyoui>
If you do not want to build everything in the library, individual components of the build can be specified:
< hyyyyoui>
Similar to above, what is the specification for ann method (if there is)?
< hyyyyoui>
Also, the normal make command does something like a clean build right? Is there a way to avoid that. Cause it takes a long time to build on my system.
< zoq>
hyyyyoui: That refers to executables, since there is no executable for the ann part it's not necessary. You can accelerate the build process if you disable the executables -> cmake -DBUILD_CLI_EXECUTABLES=OFF
< zoq>
hyyyyoui: About clean, if you don't run 'make install' it will not clean the build folder.
< zoq>
hyyyyoui: You can also disable the test build with "-DBUILD_TESTS=OFF"
< zoq>
BlakJak888: I try to reproduce the issue later, it could be a serialization problem.
< zoq>
BlakJak888: Btw. do you build against the latest master branch?
< BlakJak888>
zoq: I followed the website instructions for a Windows Build from Source and downloaded the latest release from mlpack.org
< BlakJak888>
3.4.1
< BlakJak888>
ensmallen 2.14.2
< zoq>
BlakJak888: Can you build the git master branch?
< hyyyyoui>
zoq: I was able to get better speed with your suggestions. Thanks.
< hyyyyoui>
> Moving header files to include/mlpack/
< hyyyyoui>
This line takes a lot of time after make command. Anything I can try for this?
< zoq>
hyyyyoui: You can avoid the step, don't call "make install" and link against the build folder.
BlakJak888 has quit [Remote host closed the connection]
< hyyyyoui>
i dont get you
< hyyyyoui>
the command i am runngin is make -j4
< hyyyyoui>
*running
< hyyyyoui>
do i change some flag in cmake?
gtank___ has quit [Ping timeout: 272 seconds]
vansika__ has quit [Ping timeout: 272 seconds]
vansika__ has joined #mlpack
BlakJak888 has joined #mlpack
gtank___ has joined #mlpack
< BlakJak888>
zoq : I just recompiled the latest master MLPACK code from GITHUB. The error is the same, and it disappears when commenting out the lines data::Load(modelFile, "LSTMMulti", model); and data::Load(modelFile, "LSTMMulti", modelP);
< BlakJak888>
This time the compiler failed with this error:
< BlakJak888>
D:\sdk\boost_1_74_0\boost\serialization\singleton.hpp(156,1): fatal error C1060: compiler is out of heap space
< BlakJak888>
different header, but same memory issue
< shrit[m]>
BlakJack888 These errors are not related to mlpack, these errors are related to Visual studio compiler,
< shrit[m]>
If you can use Ubuntu mlpack should build prefectly. However, if you still with VS you need to find a way to increase the heap space for the compiler.
< shrit[m]>
BlakJack888 What is the VS studio you are using?
< BlakJak888>
VS 2019 Version 16.7.5 (latest)
< BlakJak888>
I need to use Windows
< shrit[m]>
Ok, So mlpack is 3 parts. The library, bindings, and tests, which part is failing for you?
< shrit[m]>
You can compile mlpack using make mlpack -j4
< shrit[m]>
Sorry you are using Windows
< shrit[m]>
Looking at the failing code, it is probably the bindings that are failing
< BlakJak888>
I don't follow you. MLPACK compiles fine.
< BlakJak888>
It only compiles when I comment out data::Load() calls that load back the LSTMMulti model
< BlakJak888>
It looks like a boost::serializaiton issue
< BlakJak888>
Refer earlier exchange between me and zoq
< shrit[m]>
OK, I see, I over read your above comments
< shrit[m]>
OK, I see, I over read your above comments
blakjak8881 has joined #mlpack
< shrit[m]>
Sorry, it seems that boost serialization headers are consuming the entire memory in VS
blakjak8881 has quit [Quit: Leaving.]
blakjak8881 has joined #mlpack
BlakJak888 has quit [Remote host closed the connection]
blakjak8881 has quit [Client Quit]
blakjak888 has joined #mlpack
< blakjak888>
shrit : I mentioned before I am using Boost !_74_0
< blakjak888>
I tried 1_73_0 and it gave the same error
< blakjak888>
I have managed to compile and run other examples. It seems the problem is specific to this LSTM example
< shrit[m]>
We are currently working on replacing boost serialization with cereal
< shrit[m]>
The LSTM examples are working fine, The problem is related to Visual Studio.
< rcurtin>
abernauer[m]: looks like Armadillo isn't installed in /usr/local/lib/; probably you meant to use /usr/local/include/?
< abernauer[m]>
yeah I ran apt list for the dev version of armadillo and it's installed so probably the wrong directory
< yashwants19[m]>
Hey [abernauer](https://matrix.to/#/@abernauer:matrix.org) may be you can use this artifact created by github actions for installing mlpack R-bindings.
< yashwants19[m]>
You can download mlpack_r_tarball
< abernauer[m]>
ok will do
< yashwants19[m]>
👍
hyyyyoui has quit [Remote host closed the connection]
ImQ009 has quit [Quit: Leaving]
< rcurtin>
shrit[m]: the microsoft deliverability team did the same thing for me... they "implemented mitigation" but provided no reason why anything was wrong
< shrit[m]>
rcurtin that is good to here. Now I think if email is sent to an outlook address it should go to spam
< rcurtin>
if that happens, I will keep bothering them, because there is no good reason for that message to go to spam
< shrit[m]>
cereal is building on my machine, and not ont on the build farm. Also the heap issue is still present for the feed_forward test even it has been separated into two files
< shrit[m]>
I know, but they are going to say that they can not garantee that message goes to the inbox
< rcurtin>
how did you split it into two files?
< rcurtin>
ideally you want to split it in a way that not all the headers are required in both files
< rcurtin>
or at least split it such that some types are only used in one file and not another
< shrit[m]>
I know, but most of the headers are necessary in both of them I think
< rcurtin>
if you can remove any of them at all, it's likely to help
< shrit[m]>
I will try a different splitting
< rcurtin>
one more thing to possible try is to compile without optimizations on Windows... maybe that is using up RAM?
< rcurtin>
even if it is just a workaround for now, I think it is okay---in the longer term, if we can remove more and more of boost from mlpack, this should help fix the RAM usage in visual studio
< shrit[m]>
There is nothing I can remove from the ffn tests
< shrit[m]>
The one that is failing is the seconds one which contain the kmeans headers.
< shrit[m]>
The first one is not failing, as I have already remove the kmeans headers.
< rcurtin>
does the second file only contain RBFNetworkTest?
< shrit[m]>
no, I have split them equally,
< rcurtin>
ok... try with RBFNetworkTest only in the second file... let's see what that does
< rcurtin>
I have a few more ideas too... I am wondering if our use of `cotire` is causing problems on Windows
< rcurtin>
I wonder if disabling it entirely could help, or maybe the COTIRE_MINIMUM_NUMBER_OF_TARGET_SOURCES could be set lower
< zoq>
I wonder if it builds if we remove some layers from layer_types.hpp, like AlphaDropout, MiniBatchDiscrimination and SpatialDropout.
< shrit[m]>
@zoq Do you mean removing them from the boost variant ?
< shrit[m]>
Now there is only the VS15 that is failing due to this error
< zoq>
yes, and also comment the tests.
< rcurtin>
I'm not sure what CMake is setting up MSVC to do with precompiled headers... if it's not making them, that could also be the source of the problem
< rcurtin>
I *think* cotire does this automatically, but I'm not sure
< rcurtin>
I'm not sure what that will do on an OpenCL-only device though, you might need to comment out all cuda-related code in accu.cpp... I have never tried that
< zoq>
Okay, will it pick the first device, if I have more than one?
< rcurtin>
yeah, I think it will
< rcurtin>
it can be configured to pick a certain device, but I think the call to coot::get_rt().init() might need to be modified; can't remember how
< zoq>
okay, great will test it out first thing tomorrow
< rcurtin>
it should output to stdout which device it chose
< rcurtin>
if you have problems let me know, I have no idea how robust bandicoot is :-D
< rcurtin>
it works on my 3 nearly identical nvidia devices... but that's all I have...
< zoq>
I think I have an AMD card somewhere that I can test, but mainly use Nvidia here as well.
< rcurtin>
I have some truly ancient Radeons somewhere, but I think they are from before OpenCL was even invented
< rcurtin>
actually... my chromebook has an ARM Mali GPU, it might be interesting to try there
< rcurtin>
but I have no idea if there is good support for actually using it
< shrit[m]>
ARM Mali GPU, I never thought about doing GPU calculation on IOT devices :D
< rcurtin>
I would be really interested to see if it would give any speedup... I guess we can find out
< shrit[m]>
me too, I never thought about such a hardware, usually people are only looking for GPU farm calculations etc..
< shrit[m]>
I am very happy that we have Soft actor critic algorithm. Many thanks to Nishar Kumar
< zoq>
Found a Radeon HD 5970 :)
< zoq>
shrit[m]: Yeah, Nishant did a great job.
< shrit[m]>
I am trying to put it on my drones :D. I just want see if I can get something out of it, or they will eventuelly crash into some mountain
< shrit[m]>
5970 this one is old
< zoq>
Yeah, don't use it anymore, but that's what I found my shelf.
< zoq>
Nice, I think you have some sort of simulation you can test it on?
< shrit[m]>
Even it is dated 10 years, maybe it can beat my two xeons
< shrit[m]>
I have a full simulation framework I was working on it in the last 3 years.
< zoq>
Nice, if you have some results, interested to see it.
< shrit[m]>
Even it took me 3 years to write the framework, the only requirement is to have a State and Action class that are compatible with API
< shrit[m]>
Actually I never used RL on my drones, I am only stuck to Supervised learning
< shrit[m]>
Since it is harder to train a multi agent system. All the environment we have are only compatible with one agent at a time
< shrit[m]>
Once I have any results I will make a video and share it.
< zoq>
The API is all Shangtong Zhang's work.
< shrit[m]>
Yes, I know, I use the same State action mechanism in Supervised learning. I inspired my self a lot from these two classes last year, Now I happy to see that I have jsut to add some callbacks in the train function.