Stateless Service

[hughleat]

Making the service stateless would make everyone happy!
This feature req is more a place for thrashing out ideas.

Basic idea is that the service has a set of things, indexed by some hashes.
The client asks for operations to be done to a thing. The service does them and returns the results.

Two commands:

• upload(blob): hash
  This uploads a blob of something to the service. We don't need to know what it is. The hash lets it be referred to thereafter.
• apply(hash, function+): any+
  Apply some functions to the thing with the hash, in sequence (i.e. function composition). Return the result of each function.

A session might look like:

• client: apply(h1, compile-to-bc, opt(-adce), ir-size, opt(-mem2reg), compile-to-bin, binary_size)
• service: 404 - I don't recognise your h1!
• client: upload(my-C-file)
• service: h2. client can check it matches h1
• client: apply(h2, compile-to-bc, opt(-adce), ir-size, opt(-mem2reg), compile-to-bin, binary_size)
• service: h3, h4, 10KB, h5, h6, 8KB. I.e. Hashes for each command, query results for each query.
• client: apply(h5, opt(-inline), compile-to-bin, binary_size)
• service: h7, h8, 9KB. I.e. starting from an existing point, do something a little different.

The service would be responsible for caching command and query results to make things fast.

Not sure about time to live - especially for uploads.

[hughleat]

Chris, I like your idea about just having it based on hashes :-)

[ChrisCummins]

Thanks for writing this up @hughleat!

One thing I would like to take a quick look at before diving in is to see what the overhead of calculating a hash is on every step. AFAIK the best way of generating a hash for LLVM-IR is writeModule(), which might be quite expensive for larger programs.

Cheers,
Chris

[hughleat]

Possibly hashing could be avoided unless explicitly asked for:

• client: apply(h1, compile-to-bc, get-hash)
• server: ok, ok, h2

[hughleat]

BTW, could also possibly do things like:

• client: apply(h1, opt1, insn-count, h1, opt2, insn-count, h1, opt3, insn-count)
  Where each h1 resets the current thing to h1. This could be really useful for greedy search, as loads of options can be sent at once. Service at liberty to break it down and hand out bits to different machines:
• service-to-proc1: apply(h1, opt1, insn)
• service-to-proc2: apply(h1, opt2, insn)
• service-to-proc3: apply(h1, opt3, insn)

[hughleat]

Actually, upload could just be a command, too:

• client: apply(upload(blob), get-hash, compile-to-bc, ...)

From the service perspective, the client calling get-hash suggests that caching that thing for a while might be helpful. Not that it shouldn't cache other things, too, but at least make those things more likely to survive when something has to be evicted from the cache.

[hughleat]

Possibly allow get-hash to create a name that can then be reused.

• client: apply(upload(blob), compile-to-bc, get-hash(h1), opt1, insn-size, h1, opt2, insn-size)
  This allows the result from early to be reused and would be great for several searches.