3 ms·

We're a pretty heavy user of Prolog for several systems. We use it for doing end of day allocations to prime brokers to determine the optimum allocations, basi

We're a pretty heavy user of Prolog for several systems. We use it for doing end of day allocations to prime brokers to determine the optimum allocations, basically a constraint solver. I had it in the trading system for some time but I had to pull it out as I couldn't find a way to make its runtime deterministic enough. Most of the time it would be great and then on occasion I'd get 100 millisecond pauses:( I could never figure out if it was me doing something, the C bindings we were using or if Prolog just has a mind of its own:) If anyone has any pointers on how to reason about the run time efficiency and performance of your prolog code I'd be willing to buy you a coffee! http://www.amazon.com/Programming-Artificial-Intelligence-International-Computer/dp/0321417461 http://www.amazon.com/Programming-Artificial-Intelligence-In... Awesome book, can usually be found in any used university book store!

jamii 11y ago
Depending on how you are using it, you could look into an actual constraint solver like Gecode or a more deterministic logic language like Dyna. The latter would probably require some implementation work - the only production-quality implementations I know of are proprietary. http://www.gecode.org/ http://www.gecode.org/ https://github.com/nwf/dyna https://github.com/nwf/dyna
tom_mellior 11y ago
> on occasion I'd get 100 millisecond pauses As a first guess, this sounds like garbage collection pauses. Details of what to do about them depend on the particular implementation. In SWI you can use the profiler to see if the garbage collector is in fact being called when you don't expect it. Then: (a) change the default (veeery low) garbage collector settings to use more memory before collection is triggered; (b) make sure you're not leaving unnecessary choice points around (listed as "redo" by the profiler, fix with correctly placed green cuts); (c) call garbage_collect/0 yourself at well-defined points when you're currently not doing low-latency stuff; (d) possibly (but I have no personal experience with this) turn off the garbage collector completely for certain sections of the code.
- userbinator 11y ago
  change the default (veeery low) garbage collector settings to use more memory before collection is triggered I'm not familiar with Prolog GC but in other systems, making GC less frequent just tends to cause each collection to take even longer, as more objects have been created between each pass.
  - tom_mellior 11y ago
    That is true as a general trend, but in my experience with SWI-Prolog the effect is not linear, and frequent small collections do cost more (in MY applications). For one thing, if you have long-lived data used throughout the program's whole lifetime, they will be visited on every collection without ever being freed. For another thing, if you have enough memory to fit all the data ever allocated by the program, you may not need to collect at all! Also, as mentioned in my previous comment, depending on the application there may be program parts where it is OK to trigger even a long-ish collection manually, while you want other parts to be fast and collection-free. So, to reiterate: You are right in broad terms, but it all depends very much on the details of the application.
dmpk2k 11y ago
I could never figure out if it was me doing something, the C bindings we were using or if Prolog just has a mind of its own DTrace, my friend. If DTrace didn't point you in the right direction with a one-liner, I would have been surprised.
- devbug 11y ago
  Do you happen to know any good resources for becoming a power-user of DTrace?
tluyben2 11y ago
Which implementation are you using? Performance wise Mercury is a lot better than most Prolog implementations in our experience.

jamii 11y ago

Depending on how you are using it, you could look into an actual constraint solver like Gecode or a more deterministic logic language like Dyna. The latter would probably require some implementation work - the only production-quality implementations I know of are proprietary. http://www.gecode.org/ http://www.gecode.org/ https://github.com/nwf/dyna https://github.com/nwf/dyna

tom_mellior 11y ago

> on occasion I'd get 100 millisecond pauses As a first guess, this sounds like garbage collection pauses. Details of what to do about them depend on the particular implementation. In SWI you can use the profiler to see if the garbage collector is in fact being called when you don't expect it. Then: (a) change the default (veeery low) garbage collector settings to use more memory before collection is triggered; (b) make sure you're not leaving unnecessary choice points around (listed as "redo" by the profiler, fix with correctly placed green cuts); (c) call garbage_collect/0 yourself at well-defined points when you're currently not doing low-latency stuff; (d) possibly (but I have no personal experience with this) turn off the garbage collector completely for certain sections of the code.

userbinator 11y ago
change the default (veeery low) garbage collector settings to use more memory before collection is triggered I'm not familiar with Prolog GC but in other systems, making GC less frequent just tends to cause each collection to take even longer, as more objects have been created between each pass.
- tom_mellior 11y ago
  That is true as a general trend, but in my experience with SWI-Prolog the effect is not linear, and frequent small collections do cost more (in MY applications). For one thing, if you have long-lived data used throughout the program's whole lifetime, they will be visited on every collection without ever being freed. For another thing, if you have enough memory to fit all the data ever allocated by the program, you may not need to collect at all! Also, as mentioned in my previous comment, depending on the application there may be program parts where it is OK to trigger even a long-ish collection manually, while you want other parts to be fast and collection-free. So, to reiterate: You are right in broad terms, but it all depends very much on the details of the application.

dmpk2k 11y ago

I could never figure out if it was me doing something, the C bindings we were using or if Prolog just has a mind of its own DTrace, my friend. If DTrace didn't point you in the right direction with a one-liner, I would have been surprised.

devbug 11y ago
Do you happen to know any good resources for becoming a power-user of DTrace?

tluyben2 11y ago

Which implementation are you using? Performance wise Mercury is a lot better than most Prolog implementations in our experience.