Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OCaml on Baremetal Shakti RISC-V Processor

kcsrk.info

Post reply on HN
Print view View original

61–70 of 77 posts

Re: OCaml on Baremetal Shakti RISC-V Processor

#61

Post by nikofeyn »

pjmlp wrote: post #57
nikofeyn wrote: post #54

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.

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.

Re: OCaml on Baremetal Shakti RISC-V Processor

#63

Post by pjmlp »

nikofeyn wrote: post #61
pjmlp wrote: post #57

Earlier quoted context omitted.

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 th…

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.

Re: OCaml on Baremetal Shakti RISC-V Processor

#64

Post by the_why_of_y »

abhinai wrote: 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?

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/

Re: OCaml on Baremetal Shakti RISC-V Processor

#65

Post by BubRoss »

amelius wrote: post #40
nickpeterson wrote: post #39

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

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

Re: OCaml on Baremetal Shakti RISC-V Processor

#66

Post by BubRoss »

pjmlp wrote: post #57
nikofeyn wrote: post #54

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.

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

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.

Re: OCaml on Baremetal Shakti RISC-V Processor

#67

Post by yawaramin »

nikofeyn wrote: post #60
yawaramin wrote: post #59

Earlier quoted context omitted.

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 quali…

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.

Re: OCaml on Baremetal Shakti RISC-V Processor

#68

Post by oconnor0 »

pjmlp wrote: post #56
oconnor0 wrote: post #26

Earlier quoted context omitted.

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

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

Re: OCaml on Baremetal Shakti RISC-V Processor

#69

Post by nikofeyn »

yawaramin wrote: post #67
nikofeyn wrote: post #60

Earlier quoted context omitted.

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 quali…

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 t…

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

Re: OCaml on Baremetal Shakti RISC-V Processor

#70

Post by yawaramin »

nikofeyn wrote: post #69
yawaramin wrote: post #67

Earlier quoted context omitted.

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 t…

> 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 saf…

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

Post reply on HN