Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Prosper
@Prosp3r
I tool a look at blacklight code.
I didn't know you rocked go
Anthony M. Cook
@acook
The blacklight proof-of-concept is written in Go for a few reasons:
  • to not have to implement concurrency primitives right out of the gate
  • it's not C and it's simpler than Rust
  • to build a larger project in Go so I understand it better
Anthony M. Cook
@acook
The blacklight VM (at least) will be ported to a lower-level language than Go, likely Rust, when it is stable.
The blacklight compiler (which is extremely simple) will most likely be re-implemented in blacklight's blpl itself.
void4
@void4

Hi @acook !
I've talked to the author of https://computes.io/ - it's a Javascript based system. The nice thing about this approach is that it has sandboxing and multi-platform support right from the beginning. I've found a slightly different approach here: https://github.com/ewasm/wasm-metering which allows for instruction-level accounting.

Process persistence will definitely require a new VM and thus will introduce some performance tradeoffs. It's of course not required for distributed general purpose computing but might be useful nonetheless, allowing for interesting execution networks and increasing resilience in the case of failing or uncooperative nodes.

At the moment I'm trying to build a simple POC from a simple, lispy pattern matcher. An interesting observation is that if the rewriting rules themselves are modifiable, they have to be serialized with the process, requiring the base interpreter to be absolutely "frozen" (similar to https://github.com/cgyarvin/urbit/blob/master/doc/book/1-nock.markdown ). I'll also have to take a closer look at Erlang and Forth.

Anthony M. Cook
@acook
Hi @void4 !
The idea I'm working on for blacklight is that it natively understands its own bytecode as a data structure, so freezing a process and sending it over the wire should be fairly seamless aside from open file handles (which is the tricky part)
The concurrency and IPC portions I want to make nearly transparent with network computing, there should be enough so its clear to the programmer where the boundaries are so they can optimize their programs, but the interaction should be otherwise consistent and transparent
Anthony M. Cook
@acook
My end goal is that the entire system can be used together or piecemeal from datacenter up to integrating with desktop applications
The communication portion could be used alone, without blacklight, but you'd lose the ability to send running programs over the wire
Likewise blacklight can be used without the networking layer, and work fine as an embedded or standalone target VM, if you don't need (or desire) the networking component
I'd like to see a subset of the VM implemented in hardware, starting with an FPGA, as well
void4
@void4

That would be interesting.

Regarding the IO interface, it might make sense to implement the https://en.wikipedia.org/wiki/9P_(protocol) or a simplified version of it, such that processes can access external resources under a file hierarchy and pass a modified namespace to child processes, thereby sandboxing them

Anthony M. Cook
@acook
Hmm. I like P9 but hadn't really thought about doing it the same way. If the file handle object can provide locality/latency information then this might actually be a good approach. But for most applications, syncing resources to processing nodes will result in better net efficiency I'd think. Definitely worth considering the implications though.