Writing a Planner to solve a tricky programming optimization problem

Re:Writing a Planner to solve a tricky programming optimizat... by throwaway0094 on Saturday December 14, 2013 @02:34PM (#6906771)

> Its been tuned over years for use in competitions. So it probably runs faster than the author's, even though it has more features.

For OP's use case, which appears to have a max depth of maybe 3, invoking a shell program is going to be a LOT slower than just running the search. No matter how slowly it is implemented.

[ Parent | on HN ]

Re:Writing a Planner to solve a tricky programming optimizat... by tlarkworthy on Saturday December 14, 2013 @03:24PM (#6906968)

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

You are basically saying the whole UNIX philosophy of specialised reusable programs chained together is a flawed design.

Spawning a program is not slow. Store the programs file arguments on a ramdisk to avoid disk IO and there will be no noticeable overhead.

[ Parent | on HN ]

Re:Writing a Planner to solve a tricky programming optimizat... by anonymouscowar1 on Saturday December 14, 2013 @06:12PM (#6907531)

Are you kidding me? This is pretty fucking arrogant. My $DAYJOB is FreeBSD kernel hacking.

Reusable piped programs are great for some things, especially a productive shell language. No, composing processes is not great for all things, and certainly not where performance is required. This is why FreeBSD is a monolithic kernel instead of a microkernel with processes, for example.

Spawning a program is incredibly slow, even ignoring disk read times, compared to 3 levels of low-branch-factor search in any language.

[ Parent | on HN ]

Re:Writing a Planner to solve a tricky programming optimizat... by nn3 on Saturday December 14, 2013 @04:25PM (#6907167)

Your suggestion is the morale equivalent of asking to install Oracle for a simple "tiny data" database problem when sqlite or just a hand crafted table is far enough.

[ Parent | on HN ]