Malebogia

Interesting stuff! I just discovered Nim and was poking around to see if there were any "structured concurrency" implementations when I found this. If you're not familiar with them already you might want to take a look at Effect in TS and ZIO in Scala

Malebogia Locker is not re-entrant?

You can easily use Malebolgia with any lock type of your choice.

Malebogia Locker is not re-entrant?

dvars as a hack to avoid gc-safety complaints when accessing what are actually globals. My focus at the moment is to replace the threadvars by properly protected globals, on the way to making the code base thread safe and ultimately multi-threaded. I had hoped that I could use malebogia for that

Malebogia Locker is not re-entrant?

I don't believe in re-entrant locks, they mostly hide bad design. In your example, distinguish between `p2` and `lockedP2` that calls `p2` and you'll be fine.

Malebogia Locker is not re-entrant?

Or perhaps more accurately, TicketLocker? I had been hoping to use malebogia for accessing the assorted globals in the code I'm working on, but this is a showstopeer for me in that regard. Or am I missing something (again)? import malebolgia/lockers type AObj = o

Malebogia

I think you cannot really implement `reduce` and `map` with the same efficiency but be my guest and prove me wrong.

Malebogia

the new 3 procs has the same blocksize iterator pattern, wouldn't it better to extract it and reuse?

Malebogia

Done.

Malebogia

Sure, why not.

Malebogia

Looking at the implementation, it seems like the `parMap` template is actually closer to `apply` from [sequtils](https://nim-lang.org/docs/sequtils.html#apply%2CopenArray%5BT%5D%2Cproc%28T%29_2). Is it planned to include a true "map" operator? One that returns a new list that may be of a differ

Malebogia

This is great! FYI, compiling the tests throws a warning: /Users/didlibom/nim/parallel_parMap.nim(25, 7) template/generic instantiation of `parMap` from here /Users/didlibom/nim/parallel_parMap.nim(13, 10) template/generic instantiation of `awaitAll` from here /Users/didli

Malebogia

O concurrent iterable processing procedures? Nice! I haven't had to use those myself yet, but that was always one of those things I found nifty as a possible future performance optimization if I ever have a data-structure with long sequences.

Malebogia

Update: Parallel versions for `find`, `map` and `reduce`. How these work is documented in my [book](https://www.amazon.com/dp/B0B4R7B9YX).

Malebogia

> but the first thing that comes to my mind is a gym locker, which I suppose > still works in this context. That was the intended pun. :-)

Malebogia

Naming nit: why not `Locked[T]`? PS: I loves overloading too, but the first thing that comes to my mind is a gym locker, which I suppose still works in this context.

Malebogia

You have to watch out with `ref`, as usual. Wrap `ref` in an `Isolated[T]` or be careful and move them into the `Locker[T]`.

Malebogia

Very nice! This pattern looks much better than previous efforts. Are there any limitations as to what can get put into these `Locker` types? A `CountTable[string]` makes me hope there aren't many, should be able to do pretty much anything if it can handle strings and dynamically allocated memory

Malebogia

Check this out:

Malebogia

> producers and consumers are paired which can be all over the codebase Isn't that the isolation? Creator of actor doesn't know how and where it's going to be used. Who going to be sending messages to its actor. And the other way around too, the system doesn't know what's inside of actor it uses

Malebogia

I remember having memory problems when using global vars under ORC in the past. That's why I'm hesitant to use them with locks. But I'm going to retry soon with a minimal program to test the waters.

Malebogia

Exactly. Actor/Message/Channel makes it possible to work in isolation. You know only tiny part of the problem, without need to know the whole system. With threads/locks you can't work in isolation, it leaks everywhere, you need to know how the whole system works.

Malebogia

This is all wrong. Channels have nothing to do with garbage collection and are not comparable. You think "locks == low level", "channels == high level" and then draw the comparison between alloc and GC from there but it's all wrong. ;-)

Malebogia

> Exactly. Actor/Message/Channel makes it possible to work in isolation. You > know only tiny part of the system, without the need to know the whole system. > With threads/locks you can't work in isolation, it leaks everywhere, you need > to know how the whole system works. Exactly not, it's th

Malebogia

Or abstracts away a tricky problem of synchronisation, it's all a matter of perspective. Just the same way automatic memory management obfuscates the logic behind memory allocations and freeing, channels obfuscate the logic behind passing data between threads. But when the end goal is to do the

Malebogia

You don't gain anything as a channel is just an implementation detail that obfuscates the logic behind the program.

Malebogia

> Hard to reason about when it comes to blocking vs memory consumption vs > backpressure. ... the thing might consume much more memory than it needs to It's same as arguing about explicit memory management vs automatic garbage collection. Yes, you give up explicit control, to gain other things.

Malebogia

Note that if you do IO, and you block while waiting for an event in-kernel, you will block Weave load balancing.

Malebogia

Benchmark results for my M1: Malebolgia: took 486 milliseconds, 285 microseconds, and 958 nanoseconds Weave: took 865 milliseconds, 11 microseconds, and 292 nanoseconds single threaded: took 1 second, 170 milliseconds, 708 microseconds, and 875 nanoseconds

Malebogia

The ChatGPT not using its full potential, as it's won't learn on the new data. Part of conversation :) > Can you learn new data? No > So you are like Terminator 2 with the "learn" switch turned off? :) Haha, that's an interesting analogy! While I don't possess the ability to "learn" in the sa

Malebogia

Maybe the versions are different.

Malebogia

> Plus I suspect they may use some of your previous conversations for context > ... That's actually the part that impressed me the most, right or wrong answers aside, it always seemed to have **understood the context** of the full conversation.

Malebogia

You nearly always get a different answer from ChatGPT, there seems to be an element of randomness built in. Plus I suspect they may use some of your previous conversations for context, so different users would have their answers personalized.

Malebogia

Asking for "Design oversights" is a real loaded prompt, that's why. Rhymes with, "make this perfect".. Which is not an interesting ask if you do not understand the metrics for perfect yourself. There's a lot more baggage in prose than most care to know. Compositon;-)

Malebogia

The replies that you got from ChatGPT are all mostly wrong whereas mine were incredibly accurate except for the one mistake it made. Very interesting, I wonder what is going on. It's like we asked two totally different AIs.

Malebogia

thank you for responding to my suggestion. I do not know if the AI bluffs its way sometimes. I think it's at least good for quickly gaining understanding of what a code does. (explanation + documentation) This is what I got when I asked: (pasted malebolgia.nim) please explain what the following

Malebogia

Backpressure and absence of unbounded queues/channels is also crucial for availability, in applications when running out of memory is not acceptable. Also in most services response time and jitter needs to be constrained making any unlimited wait not suitable. Now, locks can be useful but they

Malebogia

Backpressure is really important for long-running apps, but blocking is not the only solution, or might be completely undesirable. For example, if your threads are sending logs through a channel and the consumer cannot keep up, the proper reactions might be anything from: * blocking * buffe

Malebogia

Update: * Now `spawn` can return a result. * Racy accesses to spawn results are prevented at compile-time. * Implements simple ticket locks that do not use an OS and don't require `deinitLock` or destructors so they are easier to use.

Malebogia

I would say with channels/actors you have choice: * let someone else (machine) solve issues you mentioned, and pay the price like higher memory consumption. * take full control, do it the hard way, and solve those issues explicitly. With threads you don't have that choice.

Malebogia

The problem with locks and atomics is that you have to make sure you do it right, and for people not used to multi-threading it quickly becomes confusing. Channels on the other hand is a more dummy-proof solution. I take something from a channel, I put something into a channel, then the channel

Malebogia

Hard to reason about when it comes to blocking vs memory consumption vs backpressure. It's easy enough to use bounded channels which then sometimes "block" but people are allergic to blocking. When you an unbounded channel which cannot block the thing might consume much more memory than it needs

Malebogia

> I don't know why you would want that, my goal is to avoid channels because > they are hard to reason about. Hard to reason about for who, the programmer or the system designer? I personally find one of the easiest ways to reason about threading is the simple "Consume input from channel -> pro

Malebogia

> At the moment they are all but unusable for any threading code. Well but its replies sounded very good. ;-) > If all threads are busy, a new task is not spawned and is instead executed > synchronously, which may cause the program to slow down but will not result > in starvation. How did it m

Malebogia

Yeah, and everything in the repository gets replaced with a Web ToDo app and all issues closed with "won't fix". :-/ LLM's are bad at reasoning, and especially bad at non-linear reasoning, even worse than humans. At the moment they are all but unusable for any threading code.

Malebogia

You should be able to get input from ChatGPT on Nim issues right now. But take it as advice only.

Malebogia

5 years later: Araq: can you please fix all issues in this repo? AI: done.

Malebogia

That's great for splitting up work into well-defined chunks and then its done. I was thinking of data sharing in more complex setups, but that is probably out of scope.

Malebogia

> I think what you said is incorrect! The `send` proc starts by acquiring the > lock of the channel and so the access to `count` is protected already. You are correct, I apologize for the mistake in my previous answer. The `send` procedure does indeed acquire the lock of the channel before acces

Malebogia

UNBELIEVABLE!

Malebogia

> Can you spot any data races, race conditions or deadlocks? I have analyzed the code and I have not found any obvious data races or deadlocks. However, there is a potential race condition in the send procedure, which updates the chan.count variable. Specifically, the count variable is not prot

Malebogia

> Can you see how to improve it further? Here are a few suggestions on how you could improve the thread pool implementation: 1. Use a work-stealing algorithm: One way to improve the performance of a thread pool is to use a work-stealing algorithm. In this algorithm, each thread maintains a q

Malebogia

Let's see. I ask: > This is a simple thread pool implementation in Nim. It uses bounded task > queues. Can you spot any problems when it comes to starvation? Run Chat GPT replied: The implementation of this thread pool appears to be well-designed and unlikely to e

Malebogia

Ask chatgpt about oversights in the code and other issues or suggestions. Ask how to fix as well. I think it's a new valuable resource. I don't presume to understand the code without hours of studying, as I have little knowledge of the subject matter, but these AIs can do it within seconds. Just

Malebogia

> Is it feasible to create channels to send to, or receive from the new thread, > but in an easy way? I don't know why you would want that, my goal is to avoid channels because they are hard to reason about.

Malebogia

🔜 Malbolge backend ?

Malebogia

It's referring to "Male Bulge", an ancient concept common not only philosophers, but also software developers, engineers, and other male-dominated industries.

Malebogia

Finally long-awaited thread abortion proc without using channels explicitly. Awesome package. This should be a part of stdlib at some point.

Malebogia

> Looks similar to > > \- which is quite promising. That was one source of inspiration, yes. > BTW is the name meant to refer to > or

Malebogia

Is it feasible to create channels to send to, or receive from the new thread, but in an easy way?

Malebogia

Looks similar to \- which is quite promising. I wonder if something similar could be used with async workers to solve the problem of unhandled exceptions. BTW is the name meant to refer to

Malebogia

Well, it's a term I invented some time ago to describe my own habit of making up product names with puns and then trying to invent the product for the name :-)

Malebogia

> Ahh, good old naming-driven development Nice, I've never heard this term before.

Malebogia

> Why now? Because it's a great new pun and I want to take credit for it. Ahh, good old naming-driven development. I'm a fan myself :-)

Malebogia

Experiments with thread pools: Contributions/feedback welcome. Why now? Because it's a great new pun and I want to take credit for it.