Skip to content


Subversion checkout URL

You can clone with
Download ZIP
My solution to the Runaway Robot prog at
Ruby C
Failed to load latest commit information.
lib DEBUG-free map & robot
.gitignore attempted short-cut(s) -- mostly a failure
.rvmrc fastest so far -- folding
145_to_236.txt correction
236_to_333.txt correction
336_to_366.txt correction
366_to_369.txt upto 510 (still 2secs, but not accepting answer)
369_to_378.txt upto 510 (still 2secs, but not accepting answer)
378_to_476.txt upto 510 (still 2secs, but not accepting answer)
476_to_510.txt upto 510 (still 2secs, but not accepting answer)
510_to_514.txt final level
Inline_Hmmc_aaf8.c new c-code working ...ready for integration; bug fix in old map; new …
MonSept6Run.txt still slow -- multi-proc/-thread doesn't work
README.txt TEXTFILE check-in
TODO.txt 173s map (not sure what slowed down from 166)
bak_solutions.txt Faster (alternating) Robot: min -Up-> mid & max -Dn-> mid
client_tcp.c no idea
client_udp.c no idea
gen_bin.rb gen_bin enables testing of binary_number generation; new robot is no …
hmmc.rb new c-code working ...ready for integration; bug fix in old map; new …
hmmr.rb cleaned-up map-validate (done_status); changed path from nil to []
jruby_output.txt txt file updates
jruby_output2.txt txt file updates
latest_rerun.txt still slow -- multi-proc/-thread doesn't work
latest_time_1-141.txt updated TEXT
level144_jruby_run.txt txt file updates
level147_jruby_threads.txt TEXTFILE check-in
longest_run.txt updated docs, after longest_run
loop_bench.rb correction
map_test.rb updated 'require' statements in an attempt to appease 1.9.2 & rbx
matrix_work.c no idea
more_solutions.txt still slow -- multi-proc/-thread doesn't work
narray_fun.txt bogus test
new_solutions.txt this is it ...trying _all_ ranges, but breaking them-up, so they're (…
new_trouble.txt fastest-yet & correct; TBD: create ?smaller? chunks; determine/try mo…
notes.txt still slow -- multi-proc/-thread doesn't work
ree_env.txt TEXTFILE check-in
robot_prof.rb cut & pasted robot_test in order to try-out profiling; still trying t…
robot_rerun.rb clean-up map, robot, rerun; reverted runaway.rb 'fix' (recreates robo…
robot_test.rb still slow -- multi-proc/-thread doesn't work
ruby-debug-base- 173s map (not sure what slowed down from 166)
run_configs.txt run_configs for robot_rerun update
runaway.rb updated runaway to maintain correct counter/level
server_tcp.c no idea
server_udp.c no idea
solutions.txt updated solutions.txt


NEW INSIGHT: min = 18, max = 31; diff=13; double_min = 36; double_max=62; THUS double_min + diff is only 49 need double_diff (26) + double_min = 62
New algorithm:
  decouple robot and map
  runaway should instantiate map, and then pass-it to the robot (via the queue?!)
  poll for Robot.path
   # which internally queries Level:<level>:Path => xxxx

  Robot accesses => x)
  Robot#map does @map ||= a call to Map.find(level)
     Map instantiates finder that calls Redis and unmarshalls the map for lvl -- unless current-level has changed...

  Use Resque (or just Redis)

  key(s) => value(s):
  CurrentLevel =>  <lvl>
  Level:<level>:Init => <optionsHash>
  Level:<level>:Map => <marshalledMapObject>
  Level:<level>:Robot => <marshalledRobotObject>

  StartJob(s) go in Queue ...we need a special type of "job" that defines this level's details
    that way many "robot"-workers and "map"-workers can get their initialization
    perhaps we just serialize a robot and/or a map
    then any agent (running on any machine) can unmarshall a robot or a map, and start processing
    the incoming request...

  RobotControl needs to initialize everybody (?perhaps?)
  RobotControl would look for the result of Map-workers -- if ever a result, publish LevelNComplete
  (possibly clean-up old level)

  Robot-workers place MapVerify Jobs in Queue (for Map-workers)
    Robot-workers continue processing -- under the assumption that Map-workers would return false

    Map-workers should be able to pull (randomly) from the "Queue"
    Map-initializer (for the current-level) ought to supply the canonical "map" for any workers that spawn-up

  The recursive Robot, will place potential solutions in that Queue

# jruby - no support for fork yet...
# -J-Djruby.fork.enabled=true 
# perhaps I should use "threads!"
# ruby --server --fast -J-Djruby.compile.fastest=true -J-Djruby.jit.threshold=100 -J-Djruby.jit.max=8192 -J-Djruby.thread.pool.enabled=true ./robot_long_performance.rb

# nah:
ruby --server --fast -J-Djruby.compile.fastest=true -J-Djruby.jit.threshold=100 -J-Djruby.jit.max=8192 ./robot_rerun.rb -n test_105

using rubinius one speed-up involves the JIT:

the default is to set the counter to 4000, but 4250 yields better results (4500 was slower, as was 3500)
ruby -Xjit.call_til_compile=4250 ./robot_long_performance.rb

# add the print option, to see other tuning-params:
ruby -Xconfig.print -Xjit.call_til_compile=4250 ./robot_long_performance.rb

ruby -Xjit.call_til_compile=4250 ./robot_rerun.rb -n test_all_levels

# too much gc, goin' on:
ruby -Xprofile=true -Xinterpreter.dynamic=true ./robot_rerun.rb -n test_105

defaults (ruby -Xconfig.print):
	gc.bytes: 3145728
	gc.large_object: 2700
	gc.lifetime: 3
	gc.autotune: true false
	gc.immix.debug: false
gc.honor_start: false
	gc.autopack: true

ruby -Xinterpreter.dynamic=true -Xgc.honor_start=true ./robot_rerun.rb -n test_105

# multi-threads:
#  rubinius
#  ruby -Xjit.call_til_compile=4096 ./robot_long_performance.rb
#  jruby
# ruby --server -J-Djruby.jit.threshold=100 -J-Djruby.jit.max=8192 -J-Djruby.thread.pool.enabled=true ./robot_long_performance.rb
Something went wrong with that request. Please try again.