On: OCaml 4.08

[newen]

What is it called when you live in an environment where X is not available and so you convince yourself that X is a bad idea?

[pjmlp → newen]

Modern security exploits and application crashes due to state corruption have proven that while threads were an enticing idea, they aren't something that we should keep around if we care about security and application stability.

This applies to all programming languages, not only OCaml, hence why everyone is moving away into other concurrency models anyway.

[newen → pjmlp]

You have two matrices, with allocated memory A and B, that you want to multiply and store to allocated memory C, as efficiently as possible using 8 cores. How do you do this without threads exactly?

[ernst_klim → newen]

>You have two matrices, with allocated memory A and B, that you want to multiply and store to allocated memory C, as efficiently as possible

If matrices are small, 1 core would be more efficient. If matrices are big, GPU would be more efficient.

[pjmlp → newen]

Vector instructions or GPGPU.

[newen → pjmlp]

Assume no GPU. Vector instructions will only use one core at a time.

[pjmlp → newen]

We are in 2019, even low level microcontrollers have dumbed down GPUs.

Plus I already answered your questions, not moving goal posts here.

[newen → pjmlp]

I wanted an efficient no threads solution to a very common problem of matrix multiplication using multiprocessor CPUs. You gave me nonsense answers like vector operations (uses only one CPU at a time) and GPUs (memory transfer bottleneck, need to copy arrays, significantly less RAM compared to CPU RAM, and GPUs make it a completely different game). So no, I'm not moving goalposts.

[pjmlp → newen]

You did not define what efficient means.

For example, a SIMD implementation will outperform a multithreaded implementation on a CPU without support for hardware threads.

My nonsense answer just happens to be what HPC is moving into, and when HPC wants to scale it uses MPI coupled GPUs, not plain old threads.

[detaro → pjmlp]

And will spend more time shuffling data through their horribly bottle-necked memory interfaces than the CPU would take handling the matrix operation, especially if the GPU is already used for graphics.

Multi-core systems and tools that can use them are valuable and very much reality right now.

[pjmlp → detaro]

Yep, CUDA and Vulkan Compute are such a waste in HPC, thankfully ML research is doubling down on threads.

[detaro → pjmlp]

You were the one who introduced GPUs on low-end embedded chips as an argument. HPC is a slightly different world.

[pjmlp → detaro]

Nah, you are the one that moved the goal posts after my first answer.

[detaro → pjmlp]

That was my first reply to you today...

As much as I often appreciate your no-nonsense perspective on things and you posting it, things like this don't really do you a favor.

EDIT: tweaked last line to be a bit less snippy

[pjmlp → detaro]

I don't always look at nicks.

[amelius → pjmlp]

There are many applications where these kind of security issues don't apply.

[pjmlp → amelius]

Such as?

Every application should strive for proper quality, just like in other industries.

[amelius → pjmlp]

For example: embedded applications, or when I'm the only one running trusted code on my computer. Think also of scientific computing.

If you insist on networked solutions: database servers.

Also: "multicore + purely functional style" is just as clean as "multiprocess + purely functional style", but ... the latter is less efficient because of communication overhead.

[pjmlp → amelius]

Unless you manage to do any kind of work without IO, there is always a security risk.

And if that is irrelevant to you, there is still the application stability and memory consistency to ensure data is being handled in a memory consistent state.

Fortran is a good example on how to do scientific computing without low level threads.

[amelius → pjmlp]

Yes threads should be used with extreme caution, that's why I advocate using a functional programming style. But you still want the performance of multicore. It's not one or the other (but with OCaml it unfortunately is).

[rwmj → newen]

I used shared memory concurrency all the time, you're simply wrong.