ccshan
2018-3-7 16:38:55

samth
2018-3-7 20:31:31

samth
2018-3-7 20:48:33

@ccshan is there another system where ClinicalTrials or LinearRegression make sense as benchmarks?


ccshan
2018-3-7 22:40:57

Good question… How about another system that performs exact inference? That would be PSI. If it is easy to install (I think it’s written in D and contains those benchmarks or some similar models already programmed). The last I checked, it only handled arrays by unrolling.


rjnw
2018-3-8 00:41:48

mallet’s first update takes 500 ms after that around 200ms each.


rjnw
2018-3-8 00:42:17

naivebayes we do a single update in 25ms but somehow our total sweep takes 40seconds


ccshan
2018-3-8 00:42:22

Cool. Did you recompile mallet and remove the nest of reporting ifs?


rjnw
2018-3-8 00:43:16

this is from the time variable they were using


rjnw
2018-3-8 00:43:19

I just printed that


ccshan
2018-3-8 00:45:00

I see so you rebuilt it with a tiny change


rjnw
2018-3-8 00:45:01

I removed the if’s but I get nullpointer after 9 trial


ccshan
2018-3-8 00:45:12

So you put the ifs back?


rjnw
2018-3-8 00:45:28

yeah with or without if the time is the same


rjnw
2018-3-8 00:45:36

the time is before that if


ccshan
2018-3-8 00:46:30

As for our performance, each sweep is 2000 updates, right? So 25ms * 2000 = 50s, which isn’t so different from the 40s you report, right?


rjnw
2018-3-8 00:46:41

oh yeah


rjnw
2018-3-8 00:46:51

I was rounding 19998 to 10000


ccshan
2018-3-8 00:47:44

So we are 8x as fast as mallet :tada:


rjnw
2018-3-8 00:50:38

for gmmGibbs our startup time from when I enter the command in shell to the point we get the compiled function prog is 1.4 seconds


ccshan
2018-3-8 00:51:14

What command?? Surely not including simplification


rjnw
2018-3-8 00:51:40

no just racket


rjnw
2018-3-8 00:51:58

this includes racket parsing hakaru and doing all the optimizations


rjnw
2018-3-8 00:52:09

I haven’t calculated simplification yet


ccshan
2018-3-8 03:58:08

So how much does the machine know about the data during this 1.4s? Does it know all the array sizes?


rjnw
2018-3-8 04:15:55

it uses runtime information like array size and actual values at the end of the pipeline, theoretically we can do all the stuff before that ahead of time and save it to disk. The compilation using LLVM is around 50ms and which is also mentioned in paper. other than that I think there are two or three recursive pass over the whole hakaru program which use this information and are also cheap.


rjnw
2018-3-8 04:16:52

a lot of it I assume comes from reading from disk parsing and doing the first subsection of optimization.


rjnw
2018-3-8 04:17:10

the runtime stuff in paper is also seperated in a different subsection