Live data from Hacker News

OCaml on Baremetal Shakti RISC-V Processor

kcsrk.info

51–60 of 77 posts

Re: OCaml on Baremetal Shakti RISC-V Processor

#51
post #6

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?

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.

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

Re: OCaml on Baremetal Shakti RISC-V Processor

#52
post #38
post #6

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?

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

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

Re: OCaml on Baremetal Shakti RISC-V Processor

#53

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.

Re: OCaml on Baremetal Shakti RISC-V Processor

#54
post #38

Earlier quoted context omitted.

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...

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.

Re: OCaml on Baremetal Shakti RISC-V Processor

#55
post #6

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?

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.

Re: OCaml on Baremetal Shakti RISC-V Processor

#56
post #23

Earlier quoted context omitted.

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.

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.

Re: OCaml on Baremetal Shakti RISC-V Processor

#57

Earlier quoted context omitted.

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...

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.

Re: OCaml on Baremetal Shakti RISC-V Processor

#58
post #6

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?

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.

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.

Re: OCaml on Baremetal Shakti RISC-V Processor

#59

Earlier quoted context omitted.

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...

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.

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

Re: OCaml on Baremetal Shakti RISC-V Processor

#60

Earlier quoted context omitted.

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.

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.

Post reply on HN