Show HN: Alan – An implicitly parallel programming language
1–9 of 9 posts
Re: Show HN: Alan – An implicitly parallel programming language
#2This looks cool. I'm curious how it compares to frameworks like Dask and Ray.
Re: Show HN: Alan – An implicitly parallel programming language
#3This looks cool. I'm curious how it compares to frameworks like Dask and Ray.
So we're very early and only do CPU parallelism right now, but we plan to tackle that problem domain in the future.
Re: Show HN: Alan – An implicitly parallel programming language
#4Interesting 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.
Re: Show HN: Alan – An implicitly parallel programming language
#5Interesting 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.
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.
Re: Show HN: Alan – An implicitly parallel programming language
#6[deleted]
Re: Show HN: Alan – An implicitly parallel programming language
#7This is incredibly impressive! Do you think this will support machine learning workloads?
Re: Show HN: Alan – An implicitly parallel programming language
#8This is incredibly impressive! Do you think this will support machine learning workloads?
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.
Re: Show HN: Alan – An implicitly parallel programming language
#9There 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.