OCaml on Baremetal Shakti RISC-V Processor | Hacker News Reader

OCaml on Baremetal Shakti RISC-V Processor

kcsrk.info

233 pointslelf76 comments

Hopefully RISC-V support will land in the mainstream soon.

It is planned, but requires availability of actual hardware for testing.

OCaml is a beautiful language but I haven't seen any big non language projects written in OCaml. Does any one know why? OR do such projects exist and it is only that I am not aware of them?

When you say non-language, do you mean unrelated to OCaml specifically or any language? Facebook implemented its infer linter for C, C++, Java, and Objective-C in OCaml: https://github.com/facebook/infer. When I worked at Bloomberg, they released BuckleScript for JS development. Not sure if that caught on though.

Bucklescript has caught on to some extent. Its sister syntax ReasonML is getting a little traction which means that Bucklescript is getting a little traction as they share the same build chain.

Facebook Messenger is built using Reason. A few other smaller companies are using it too: https://reasonml.github.io/en/users-of-reason

Wow Air were using it though one probably can't blame that for their collapse.

I guess that list doesn't include straight Bucklescript users either. There are definitely companies out there who use it outside of Reason so the OCaml, in general, is getting some use in industry which is nice.

https://www.janestreet.com/technology/

Unison File Synchronizer is written in OCaml.

There's Zero Install: http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...

A lot of thereom proving is done in Isabelle/HOL, a DSL in OCaml.

Hol is in sml. HolLight is OCaml.

There's a (unofficial) FUSE file system for Google Drive written in OCaml: https://github.com/astrada/google-drive-ocamlfuse

https://mirage.io/

ReasonReact is a fantastic project that is written in OCaml (with Reason syntax). In addition to being a wonderful frontend framework, it's also a great introduction to the language.

A lot of Xen is built in OCaml

The Tezos blockchain / dapp platform is based on OCaml. This to me makes it really appealing, if I were to find some actual use case for a blockchain application :)

This is OCaml's problem: it's a great language with no users. ReasonML is trying to solve this by making it more approachable, and they're making steady progress.

There are some really cool projects popping up with ReasonML - here are a few:

- A package manager like NPM, but for native code: https://github.com/esy/esy

- A fast Node version manager: https://github.com/Schniz/fnm

- A fast replacement for dotenv-cli: https://github.com/ulrikstrid/reenv

- A fast JS bundler: https://github.com/fastpack/fastpack

- A native language server: https://github.com/jaredly/reason-language-server

The OCaml language and toolchain is very powerful... and I do believe ReasonML makes it more approachable, at least for a wider audience of developers comfortable with JavaScript-style syntax.

I think you forgot one ;)

- A native GUI: https://github.com/revery-ui/revery

> This is OCaml's problem: it's a great language with no users.

My other post in this thread proves the opposite.

It's hyperbole. Relative to larger languages, there are few users.

Yes, there are also poor languages with many users :-)

OCaml is very good at symbolic computations, and not so good at floating point computations. Therefore it's a very good language for writing compilers etc.

Further than that, there are no more programs written in it for the same reason than there are no more programs written in any interesting languages, I guess; ie largely accidental.

> and not so good at floating point computations

What does this mean? I was under the impression the OCaml compiler did a decent number of floating point specific optimizations, like unboxed arrays and what not.

Surprised me as well janestreet are a well known user of ocaml and I can't imagine they don't use a lot of floats.

I guess it is the typical complain about using separate operators for ints and floats.

It never bothered me in Caml Light, let alone when Objective Caml was introduced.

Ah, maybe, perhaps I am in the minority that liked the different operators for ints and floats. :D

You can write floating point operators in several different ways. You can write with the normal floating point operators

    x *. y +. z

or, since `Float.(+) = (+.)`, `Float.() = (.)`, etc,

    let open Float in
    x * y + z

or simply

    Float.(x * y + z)

That is pretty neat. Does it mean that one could do something similar for vectors and quaternions?

    let open Quaternion in
    x * y + x

Yes.

Yep. You could write

    module Quaternion = struct
      let (+) =
        ...
    
      let ( * ) =
        ...
    end

then

    let open Quaternion in

imports the contents of Quaternion into local scope, so you can write

    x * y + z

Symbols (variants with our without parameters) and integers are unboxed, while floats are not (but in a few specific cases such as arrays of floats, and iiuc that's an inelegant special case on its way out, as it prevents other optimisations).

Frama-C and Why3. Okay, maybe they're somewhat "language" projects since one is parsing C and another has its own language :)

The Fastest Fourier Transform in the West (FFTW) library is an example of a ubiquitous software product using OCaml. The FFTW library is a C library, but it is in large parts generated by an OCaml program, genfft (from the FAQ http://www.fftw.org/faq/section2.html#languages)

Companies using OCaml: https://ocaml.org/learn/companies.html

What is OCaml used for? https://www.quora.com/What-is-OCaml-used-for?share=1

Further infos:

awesome-ocaml - A curated collection of awesome OCaml tools, frameworks, libraries and articles: https://github.com/ocaml-community/awesome-ocaml

OCamlPro Research and Development: https://www.ocamlpro.com/research-and-development/

OCaml Weekly News (RSS): http://alan.petitepomme.net/cwn/cwn.rss

> any big non language projects written in OCaml

Coq proof assistant (https://coq.inria.fr). Well, you can say it is language-related, but it’s a lot more than that.

I'd love to use it, but there seems to be no multicore support.

I obviously don't t know your use case, but the more I look into multi-core code, the less impressed with it I am. I think you're almost always better with a tight loop and a good persistence strategy. If the thing you're doing really benefits trivially from easy paralellism, I'd lean on gpus anyways...

Well one usecase I have in mind is a fast distributed datastore that integrates well with the rest of the language. This means I need threads, to do transaction processing. And I also need shared memory at the language's object level, allowing structural sharing for efficiency.

It could be worth taking a look at this, it sounds like an example of what you want (C++11)

https://github.com/LiveAsynchronousVisualizedArchitecture/si...

basically every program i have written has been concurrent and benefited from multi core support. a language that doesn’t have it just isn’t an option.

Security exploits and plugin crashes on the other hand prove there is a benefit in using multiple processes instead.

well, trade offs are trade offs because then one has to worry about intraprocess communication. can you elaborate on security exploits? i would assume a closed off system with interprocess communication would be less vulnerable than that with intraprocess communication, which seems like it could be intercepted. but i do not know much about security.

process crashes are of course a problem in terms of bringing down the whole process, but that generally isn’t a problem for me.

Each process would execute with the minimal set of permissions that it needs to perform its tasks.

Whereas in interprocess, each thread can do everything that the whole process is allowed to do, so a security exploit in e.g. file parser, opens the door for doing other stuff that a file parser shouldn't be allowed to start with.

An easy to use IPC is to use pipes, mailboxes, message queues, just like channels.

Yes it might be slower, but for a large set of problems it is fast enough.

I think both are more a matter of architecture. There are many different ways of finding parallelism and they all have their place. There is no single silver bullet and more parallelism and concurrency are generally the right direction to make use of modern hardware.

Do you have any analytical benchmarks regarding the benefits you've gotten from multicore support?

well just today i sped up a simple algorithm by a factor of two or three on larger data sets by simply turning on parallelism in a for loop, which distributes iterations across cores and then merges them afterwards. so multicore performance came for free.

in other instances, when programming concurrent programs, i have no worry of performance losses because, again, multicore support comes for free. that is more qualitative, but it is important. and it means my concurrent programs are actually concurrent.

Regarding your simple algorithm, that's great but map/reduce is a well-known 'embarrassingly parallelizable' algorithm. If the majority of your code is map/reduce that's great for you but a lot of code is not trivially parallelizable like that.

The problem with 'no worry of performance losses' with multicore is that using multiple cores itself has a cost. You need to split up your workload, schedule the work across the cores, pass the actual data as messages to whatever 'task' abstraction you're using, and unless the garbage collector has fancy tricks, this will mean having to deep-copy the data to preserve thread safety. So again, there's no such thing as a free lunch in multicore.

> If the majority of your code is map/reduce that's great for you

who said it was? (it isn’t.) you asked for examples, and i gave the most recent one.

> You need to split up your workload, schedule the work across the cores, pass the actual data as messages to whatever 'task' abstraction you're using, and unless the garbage collector has fancy tricks, this will mean having to deep-copy the data to preserve thread safety.

you’re making a huge amount of assumptions and supposed “costs” here based upon the rather limiting nature of most programming languages when it comes to concurrency. most of the multicore programming i do is with actors with a data flow language. multicore programming is so trivial you don’t even think about it.

> who said it was? (it isn’t.) you asked for examples, and i gave the most recent one.

OK, but then, outside of that kind of use case, most applications are not trivially parallelizable like that.

> most of the multicore programming i do is with actors with a data flow language. multicore programming is so trivial you don’t even think about it.

Maybe I miscommunicated, but I don't mean that you literally are doing all these things, but that something is–some combination of the language, the runtime, and the developer. My point is that no matter who is doing it, these things have costs–runtime performance, memory use, limits on the usable data structures and programming techniques.

We're working on it https://github.com/ocamllabs/ocaml-multicore

I’m a huge OCaml fan, but really it lacks a lot of things that you get out of the box with the runtimes of other languages. Multi core support is the most obvious one.

It’s definitely great for things like compilers, though. But I wouldn’t necessarily use it for a Web server.

It's even great to draw nice fractals: https://github.com/cedricbonhomme/iterated-function-systems ;-)

Multicore support is imho nowhere near OCaml's top problem :-) that would probably be a toolchain that lends itself to easy reproducible package management. But we're getting there.

We're working on it. You can install and play around with Multicore compiler today though the wider library ecosystem is yet to catch up. https://github.com/ocamllabs/ocaml-multicore

Not everything needs to be usable for a Web server. I also wouldn't use C or C++ for anything directly plugged into the network. Morris worm proved what happens 30 years ago.

Besides, there are also multiple processes as possible solution.

There is: https://bitbucket.org/skskeyserver/sks-keyserver/

As someone who tried to get into it :

- the syntax is not great. I've heard it's one of the reasons why F# was born

- not many people use Ocaml, which makes it hard to find help

- not many good resources. The official documentation is really hard to parse and there isn't much besides it and the reference book (which reads more like a book than a reference).

- no good ways to debug, print objects, test, etc.

- no one seems to agree on what is the standard library or the correct packages to import (for example there are several Option package)

> MetaOCaml has been successfully used for the most optimal stream fusion, specializing numeric and dynamic programming algorithms, building FFT kernels, compilers for an image processing and database query DSLs, OCaml server pages, generating families of specialized basic linear algebra and Gaussian Elimination routines, and high-performance stencil computations.

http://okmij.org/ftp/ML/MetaOCaml.html

I’ll add to all the examples in this thread that the Rust (also partly of ML descent) compiler was written in OCaml until it became self hosting.

I’ll also +1 the comments about ReasonML which is very promising.

Though I suppose these are both ”language” related — just not strictly the OCaml language.

The tooling around libguestfs, a library for manipulating disk images that is typically used with KVM/Qemu based virtualization, is implemented in OCaml; the library itself is implemented in C.

https://rwmj.wordpress.com/2017/06/04/new-in-libguestfs-rewr...

http://libguestfs.org/

I like the direction Shakti team is taking with the project, skilled personnel teasing practicality; Although I believe that the secure application project is intended for defence purposes.

Secure applications are pervasive. Think point of sale terminals, IoT devices and wearables handling personal information, all fly by wire systems, etc. Shakti is a whole family of processors from tiny microcontrollers to server class processors.

Where can we get this RISC-V hardware?

https://riscv.org/risc-v-cores/

The shakti in particular...

Not available on that site.

There is a link to the code (hosted on Gitlab).

There is always a mention of F# whenever discussion on Ocaml arises. This time I wonder it is not discussed as much here because may be F# is clearly at disadvantage in RISC-V domain.

Ironically, the bootloader is still assembly with C++. Then again, maybe that is not the interesting thing to do in OCaml.

I'm not sure that's ironic. I believe the OCaml runtime is written in C as well.

Many times that is a matter of convenience, other than trying to prove a point doing a full bootstrap.

Malte here, I developed the bootcode. While I agree with you, it's about the minimum you can do in C/ASM land before starting up OCaml. The bootcode just initializes the registers to zero, setups a trap handler and the stack and heap. This is impossible to do from OCaml as it does not allow direct register/memory access as a language feature.

Both spike and qemu-system-riscv are now available in Arch Linux.

Shakti will be used in next iPhone I guess.

Why? I’m honestly interested in you’re theory.

Wasn't MirageOS bought by Docker Inc? Is the project still independent and active?

Docker did acquire Unikernel Systems, but MirageOS is alive and well.

Reply on news.ycombinator.com