3 ms·

Show HN: Alan – An implicitly parallel programming language

47 points by ISV_Damocles 6y ago

wskinner 6y ago
This looks cool. I'm curious how it compares to frameworks like Dask and Ray.
- ISV_Damocles 6y ago
  So we're very early and only do CPU parallelism right now, but we plan to tackle that problem domain in the future.
econti 6y ago
Interesting idea. Are there any performance benchmarks that you've run and can share? I'd really like to get a sense for what kind of improvements you've seen for computationally heavy tasks vs. a language like Go or Python.
- ISV_Damocles 6y ago
  Still working on those. :) We definitely beat Python, and we're faster than Node.js and Java at startup time. Where we are in the spectrum from C to Ruby we don't exactly know yet. But we do expect to improve and get much much closer to C as we make improvements to our runtime, such as writing a JIT for the VM.
deleted 6y ago
[deleted]
Jorghi12 6y ago
This is incredibly impressive! Do you think this will support machine learning workloads?
- ISV_Damocles 6y ago
  We think the design of the language will support that in the future, but we need to write a GPU-based runtime that lives inside of the runtime and get it to decide when to offload work to GPU first, and that will take time.
ISV_Damocles 6y ago
There was a question earlier from someone who wanted to know how Alan compares to NESL and Fortress. We took too long to draft up our response and were surprised to find it deleted when we got back. In case you're still lurking, we wanted to give you our answer. :) Our array-level parallelism is very similar to NESL's, but we also include IO concurrency based on dependency graph analysis and a coarser Event-level parallelism. Fortress does share many similarities with Alan, including being able to declare your own operators, but is a runtime typed language while Alan is compile-time typed so we should have a higher performance "ceiling" in comparison. We're also owning the runtime entirely so we can make optimizations that a JVM-targeted language would not be able to.

47 points by ISV_Damocles 6y ago

wskinner 6y ago

This looks cool. I'm curious how it compares to frameworks like Dask and Ray.

ISV_Damocles 6y ago
So we're very early and only do CPU parallelism right now, but we plan to tackle that problem domain in the future.

econti 6y ago

Interesting idea. Are there any performance benchmarks that you've run and can share? I'd really like to get a sense for what kind of improvements you've seen for computationally heavy tasks vs. a language like Go or Python.

ISV_Damocles 6y ago
Still working on those. :) We definitely beat Python, and we're faster than Node.js and Java at startup time. Where we are in the spectrum from C to Ruby we don't exactly know yet. But we do expect to improve and get much much closer to C as we make improvements to our runtime, such as writing a JIT for the VM.

deleted 6y ago

[deleted]

Jorghi12 6y ago

This is incredibly impressive! Do you think this will support machine learning workloads?

ISV_Damocles 6y ago
We think the design of the language will support that in the future, but we need to write a GPU-based runtime that lives inside of the runtime and get it to decide when to offload work to GPU first, and that will take time.

ISV_Damocles 6y ago

There was a question earlier from someone who wanted to know how Alan compares to NESL and Fortress. We took too long to draft up our response and were surprised to find it deleted when we got back. In case you're still lurking, we wanted to give you our answer. :) Our array-level parallelism is very similar to NESL's, but we also include IO concurrency based on dependency graph analysis and a coarser Event-level parallelism. Fortress does share many similarities with Alan, including being able to declare your own operators, but is a runtime typed language while Alan is compile-time typed so we should have a higher performance "ceiling" in comparison. We're also owning the runtime entirely so we can make optimizations that a JVM-targeted language would not be able to.