Usability of ARC/ORC in multi threaded code.

I don't know if it's the best example, but it's one example: The Node ref could be a global protected by a read/write lock.

How can I create a process completely detached of my process?

Yes, @archnim, code is executed after the child process dies out.

Atomic ARC

I started this thread surprised by the little overhead but it turned out to be true only for most modern CPUs. An overhead of 10% for some/most CPUs is quite high. However! What a modern CPU does today is what most other CPUs do tomorrow so `atomicArc` seems to have a bright future. On the othe

Atomic ARC

Ah sorry, you changed the order in the second half of your post on the github.

Atomic ARC

> Araq's M1: 5.1% slow down For me atomicArc than arc was slightly faster on the M1.

Atomic ARC

> Ah so you do not want to get rid of arc :P If you have --threads:on you have atomic ARC. If you don't have threads on you don't have atomic ARC. This is a tiny thing. The important distinction is that the --threads:on + non-atomic ARC which is a non-functioning combination is removed and neve

Atomic ARC

The presumption is that your `JsonNode` is concrete in both worlds. It is a generic in my world. In my proposition all ref objects would be a generic that can be either an atomic or not. So the compiler does need to do anything but instantiate the type/procs when used. As `{.atomic.}: JsonNode`

Usability of ARC/ORC in multi threaded code.

I would wonder how more than one thread could have a reference to `Node` safely. It seems to create the scenario in question (the `query` call in relation to threads) we'd already have done something troublesome.

Atomic ARC

I think there are further issues with this. If I understand correctly, importing code that tagged JsonNode (or any other common type) as an atomic ref would need to suddenly make all JsonNodes atomic refs throughout the entire compilation unit. This is necessary to ensure aliases work. This is p

Is it bug of pragma nodecl?

I want to define a var in c with "char x[] = {'h', 'e', 'l', 'l', 'o', 0};" to make the varaible allocate on stack, and doesnt refrence any global variable. (The code will be remote execute with CreateRemoteThread). So I wrote a macro and using importc to import the varaible, the code is:

Atomic ARC

Marking an object as Atomic could propagate downwards to all `ref` types(unless annotated non atomic). In doing such all `ref T` could be a generic that would accept `ref[{.atomic.}:T]` and `ref[T]`. Which means we now have Atomic functioning on a per object basis without overhead everywhere and

Atomic ARC

arc 5.859s; 490.560MiB peakmem; atomicArc 5.767s; 490.650MiB peakmem; Very close times and memory basically.

Few async tools for nim

It's just an alternative pattern that someone can prefer in some situations, to add a callback to an existing future.

Package update issue

Ah ok. Thank you.

Package update issue

It finally downloaded the latest version, after I tried several times.

Package update issue

Shameless self promotion of a git tagging tool `graffiti_` simply tick your nimble file then `graffiti ./your.nimble` and it'll create a version for all ticks you've ever done.

Atomic ARC

I can see merit in a pragma but it has issues. Every ref type that is a field of ref type marked to be atomic would also need to be atomic, else it is kind of misleading / strange. If I make a `Dummy = ref object` with a JsonNode field, I can mark Dummy atomic but the JsonNode field would not b

Usability of ARC/ORC in multi threaded code.

One question that's been on my mind regarding multithreading with ARC/ORC (without atomic refcount) is the relation with `lent T` return type. What I mean is that with [strict funcs](https://nim-lang.org/docs/manual_experimental.html#strict-funcs) we already have a nice way to prevent mutation

Atomic ARC

Yes non atomic arc should still exist. As long as there is a overhead from the atomic and usages where multi-threading is uncommon or impossible there is a reason for no added overhead even as negligible as atomic can be. Yes this an issue, but I really think there should be some sort of annotat

Package update issue

You update version in the package.nimble after tagging , . Do before .

Package update issue

Hello world ! To update my nimble package: * I Updated the the version in package.nimble * I Created a new release on github with a tag When I uninstall and reinstall the package, nimble prints: Cloning latest tagged version: v0.1.1 Verifying dependencies for sunk@0.1.0

Few async tools for nim

How is this: import std/[asyncdispatch, httpclient] var client = newAsyncHttpClient() f = client.getContent("https://google.com";) f.then do(): echo "Finished with success !" f.then do(return_value: string): echo return_value f.catch do(): ec

Atomic ARC

When running the commands, I get 3 `iterations` on each command, which one do I report?

Atomic ARC

AMD Ryzen 5 5600x + Windows 10 for this benchmark `mm: arc; threads: on; opt: speed; options: -d:release 165616 lines; 8.583s; 489.793MiB peakmem` `mm: atomicArc; threads: on; opt: speed; options: -d:release 165616 lines; 8.646s; 489.805MiB peakmem`

Atomic ARC

Is there any difference when targeting amd64 vs arm64 on M1?

Usability of ARC/ORC in multi threaded code.

Why did you have to change it? The original makes sense as long as the return type can't alias any part of `y`

locks on dynamically allocated memory

Thank you for the complete and clear code sample. I understand now.

Atomic ARC

Interesting, on my M1 atomicArc beats arc.

locks on dynamically allocated memory

Thank you for the complete and clear code sample. I understand now.

locks on dynamically allocated memory

Worth noting the guard clause can be used on fields. type Thing = object val {.guard: Lock.}: int lock: Lock Run

Atomic ARC

arc: 5.519s; 491.391MiB peakmem atomicArc: 5.750s; 491.387MiB peakmem Run Apple M1

Usability of ARC/ORC in multi threaded code.

Ah, I think later in the implementation I had to change the `or` to an `and`. And the RFC wasn't updated. You're right!

Usability of ARC/ORC in multi threaded code.

Those where the rules I was referring to. In this case `x` is a function call, it is `.noSideEffect` (after the echo was removed) and has one argument, let's call it `y` here instead of reusing `x` like the RFC. `y` is not isolated as it is a ref type stored in a variable, but looking at the _o

bug (?) with nested templates in generic proc

Generics with macros can cause some very odd issues, simply due to how generics work. What is happening here is that the compiler sees the macro is untyped and attempts to expand it in the declaration resulting in an incorrect behaviour, we can hack around this by giving the template a typed par

Usability of ARC/ORC in multi threaded code.

>From the RFC: If `T` does not contain a `ref` or `closure` type, it is isolated. Else the syntactic structure of `x` is analyzed: * Atoms like `nil`, `4`, `"abc"` are isolated. * An array constructor `[x...]` is isolated if every element `x` is isolated. * An object constructor `Obj(x...)

Few async tools for nim

Excellent. Always happy to see more async libs

Few async tools for nim

This looks really nice, I've been wanting something like this :)

Atomic ARC

You might need to recompile `koch` first. `nim c koch.nim`

Usability of ARC/ORC in multi threaded code.

I was thinking of the rules for isolation as laid out here: . According to that `f(...)` is isolated if it can't have side effects and the return type can't alias the input types. In my example I return a `Tree` type which can only alias `Branch` typ

How to cast or pass a {.closure.} as a callback to a C API with userdata pointer?

I couldn't make the `rawEnv` and `rawProc` work mostly because I don't have control over the order of parameters passed to the proc to make sure the userdata is passed around correctly. Instead I wrapped the `proc` type inside a tuple that I allocate before making my C call, and I store this tu

Few async tools for nim

Hello world ! Just to tell you that I've published a small package that provides some asynchronous programming features like `then` and `catch` for futures. * Repo: * Docs: Feel free to suggest improvements 😉.

locks on dynamically allocated memory

This is one way to do it. There are probably nicer ways, but this is pretty explicit to show what is happening. import std/locks type Thing = object val: int lock: Lock ThingInfo = object thingPtrs: ptr UncheckedArray[Thing]

Atomic ARC

Hint: mm: arc; threads: on; opt: speed; options: -d:release 176527 lines; 6.574s; 609.012MiB peakmem; Hint: mm: atomicArc; threads: on; opt: speed; options: -d:release 176527 lines; 7.462s; 609.34MiB peakmem; i7-6700K ddr4 2666

Atomic ARC

Sorry, I didn't read very closely. I'll give it a go on my Ryzen 5 3600 when I get the chance.

Atomic ARC

@Araq I can test if you provide some benchmark code, I don't have anything ARC-usable on hand that'd be suitable

Atomic ARC

As I tried to say, "bootstrapping" (the Nim compiler compiling itself) is a useful benchmark.

locks on dynamically allocated memory

No, the guard is not what you are looking for; you will need to put a regular mutex in your object and manually lock/unlock it when you are accessing your data. The .guard informs the Nim compiler about your intentions with regards to locking, it can help you protect your data by warning you th

locks on dynamically allocated memory

Please, can you write a short example code ??

Atomic ARC

This [pull request](https://github.com/nim-lang/Nim/pull/21798) improves the thread safety of ARC with surprisingly little overhead. For some CPUs. Please help us by joining our benchmarking efforts. Please report: Stats for `koch boot -d:release --threads:on --mm:arc` Stats for `koch boot -d

How to cast or pass a {.closure.} as a callback to a C API with userdata pointer?

You can access the environment with [rawEnv](https://nim-lang.org/docs/system.html#rawEnv%2CT) and the function pointer with [rawProc](https://nim-lang.org/docs/system.html#rawProc%2CT)

How can I create a process completely detached of my process?

That is called **fork**.

locks on dynamically allocated memory

> put a lock in these individual elements The only way to attach a lock to a memory space, that I know, is to add a pragma in a variable declaration: var num {.guard: lock}: int Run How can i use them on dynamically allocated items ?

How can I create a process completely detached of my process?

Is there any code after the `execCmd` that is not executed ?? If not, then it's normal for the parent to die after the child is killed. (Are we on a hitman forum ? 😄 😁)

How to cast or pass a {.closure.} as a callback to a C API with userdata pointer?

This would indeed be very cool. I don't think Nim currently exposes these in any way, so the only way to potentially do this would be to wrangle that information out yourself. I would love for something like this to be available and supported in Nim though!

locks on dynamically allocated memory

If you make a seq of objects, you should be able to access the individual elements of the seq by their raw pointer address from your threads, and put a lock in these individual elements for fine grained locking of their contents. >From your different threads perspectives, ignore the fact that th

locks on dynamically allocated memory

Sorry for insisting. Is there a way to guard a sequence item with a lock ? It would be a waste of time if all my threads had to wait for the same lock (that of the entire seq) to access objects that often don't interact with each other. Thanks in advance.

Question from a complete Newbie

You mention that you installed Nim a while ago, which version of Nim are you using? If you're using an older version but reading the latest docs this might be the reason for the contradiction, especially since @void09 seems to not be able to replicate your issue. By the way, I took the liberty

How can I create a process completely detached of my process?

Hello everyone, so recently I've tried to make a program that spawns another process, and I use `os.execCmd` for this. It works, but the problem is that if the child process is killed, the parent dies too. Is there any way to detach this child from the parent process? Thanks, and I'm sorry if an

Is ORC considered production-ready? What is the consensus on its use?

> garbage collector which is a central piece of the language > ORC changes > everything because it changes how to write well-written Nim Hmm, I would say it depends very much on what you do. If you build performance critical app, those things are important, and your code will be affected. But m

Question from a complete Newbie

I tried your code and it works with both H and HH, and shows the correct result, according to the format: Don't see a problem, check your code again.

Question from a complete Newbie

I am just starting to try and learn more about Nim having installed it a while ago. My idea was to go through the exercises from the (free) online book 'How to think like a Computer Scientist with Julia' which I had worked through a while ago - using Julia of course. For the exercises, my intent

bug (?) with nested templates in generic proc

Hi there, I have something like: import std/macros template someTemplate(body: untyped) = macro someInnerMacro(innerBody: untyped) {.inject.} = newCall(ident"echo", newLit(innerBody.repr)) body proc test[T](x: T) = someTemplate: som

How to cast or pass a {.closure.} as a callback to a C API with userdata pointer?

Hello, I've been using Nim for a little while but until now I never dig in that space of C API, at least not enough to encounter C callbacks. I want a simple thing, pass a function pointer to C code and get the C code call my proc later on. Luckily enough, the C API provides a userdata pointer

Is ORC considered production-ready? What is the consensus on its use?

"Production ready" means a lot of different things for a different people, but the way we have come to look at the roadmap is more or less: * ORC represents a major shift in the garbage collector which is a central piece of the language - the "minimum viable release" level of quality is that

Good Languages Borrow, Great Languages Nim

It also rhymes with Vim, which is another tool known for sacrificing familiarity for power and usability.

Is ORC considered production-ready? What is the consensus on its use?

This should help: More fixes are in the pipeline.

Usability of ARC/ORC in multi threaded code.

Here is the PR adding an experimental mm:atomicArc switch booting: 6.374s (--mm:arc --threads:on) 7.107s (--mm:atomicArc --threads:on)