search

ariesteam / aries

http://www.ariesonline.org
GNU General Public License v3.0
6 stars 1 forks source link

riskwiz too memory intensive to run at high res on local installations #16

Closed kbagstad closed 12 years ago

kbagstad commented 12 years ago

Gary and I tested several BNs on local installations versus huginn and found that there was extreme slowness (to the point of hanging) associated with running on local 64-bit installations with riskwiz. Gary's plan is to reinvestigate riskwiz to look for ways to speed it up.

fvilla commented 12 years ago

Yes, I was worried about this. Not much I can do except triple-check that it's been used correctly within Thinklab... we can definitely profile RiskWiz to see if there's any obvious hangup point. Can someone post some of the offending models?

Also, any funding incoming so we can get someone to develop a BN package under Gary's guidance? 6 months of funding for a good student may be enough.

lambdatronic commented 12 years ago

I think this ought to cause the offending hang:

model -d core.models.carbon-san-pedro/identification-carbon core.contexts.beta/san_pedro_us512

Since it hangs the same for Ken and myself but works without a hitch on huginn, I have to presume that this is just a resource constraint issue with RiskWiz (probably a memory leak or something that is leading to JVM virtual memory thrashing). I had Ken crank up his JAVA_OPTS to give his JVM 6GB of RAM, and that still didn't fix the issue even at res 256. Sad sad. Clearly a need for a rewrite.

fvilla commented 12 years ago

No, huginn is using genie with the 64-bit dll that's not available on win. The analysis is probably still correct but I'm pretty sure it's not a matter of adding memory - either an infinite loop it gets into in some situations, or a monster leak somewhere.

lambdatronic commented 12 years ago

Ah, good to know. Thanks, Ferd.

~Gary

Ferdinando Villa reply@reply.github.com writes:

No, huginn is using genie with the 64-bit dll that's not available on win. The analysis is probably still correct but I'm pretty sure it's not a matter of adding memory - either an infinite loop it gets into in some situations, or a monster leak somewhere.

() ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Please avoid sending me MS-Office attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

fvilla commented 12 years ago

...tested with the 64bit genie dll I got and put on the RAID. Worked without a hitch on win - success. This should take care of our needs for now, certainly not remove the need for a properly open source and working BN implementation, but that's another story so I'm closing this one and we should update everyone to use that. I am committing the dll as 'genie.dll' and renaming the 32bit 'genie32' so it's all in one place, we worry about the rest later.