Atomic ARC

Since then the allocator became lockfree...

Atomic ARC

> Just turning on --threads seems to be a performance killer. Wasn't that because of the lock/unlock dance on memory allocation? Can this be reproduced with `-d:useMalloc`?

Usability of ARC/ORC in multi threaded code.

Just an idea about proving that variable graph is isolated. Maybe it could be done same way as out of bound runtime check is done, at runtime. In dev mode each ref variable has a field with thread id, and if that id is different from the current thread id when you touch that variable, the except

Usability of ARC/ORC in multi threaded code.

My English is not good. Still, I will try to explain what I had in my mind a bit more before I give up. I was answering these: > Araq: How can you assume a lock on the "root" Node? The compiler has no idea > about a "root" node > > PMunch: Indeed having a rule like "every local variable involv

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

Can you post a minimal code with the bug in it ?

Usability of ARC/ORC in multi threaded code.

Sorry, maybe it was 8-9 years ago when I've last time looked nim compiler source. I'm not exactly sure what I'm talking :) but I was thinking, you have to track and store information about every assignment, every access to that data in every module to make isolated work. Compiler then would need

Atomic ARC

> Just turning on --threads seems to be a performance killer. Told you this like months ago. Maybe default to `--threads:on` needs to be reconsidered?.

Usability of ARC/ORC in multi threaded code.

> Just a thought. Ignore it if its indeed a stupid idea. You're describing `Isolated[T]` and `isolate` and we're trying to figure out how exactly it can work.

pure nim io_uring library

I stopped changing the implementation often enough, so I think now I can show everyone

Usability of ARC/ORC in multi threaded code.

Most probably I'm being stupid here but cant you invent a new return type which cannot be assigned to a variable and cant be changed after returned from a proc? Then If threads:on, wouldnt it be possible to prove it that it is really not touched after its built in extra compiler pass ? proc bui

Usability of ARC/ORC in multi threaded code.

> I could whip up a realistic example, but without a working isolate system > it's hard to make sure the entire thing is correct. Yes, please do that. And it's not hard to do: Instead of `isolate` use `unsafeIsolate` to make the compiler shut up. And use valgrind/some sanitizer to make sure it'

Is it bug of pragma nodecl?

Great! using pragma `global` works. The assembler code is same for both make_nim_char_array and make_c_char_array with msvc compiler flag `/O2`.

Why `!=` is template and not a func?

> to show off the language feature ;) IIRC I needed `!=` and an implementation of generics did not exist yet. ;-)

Why `!=` is template and not a func?

I assume that's mostly to make sure that the correct `==` is chosen. With untyped the template doesn't limit or coerce the type at all, so it's passed directly through.

Usability of ARC/ORC in multi threaded code.

> The result of the query borrows from the n parameter, and in theory the > lifetime dependency can avoid refcounting activity since it's assumed that > the lending parameter is reachable in the first place and the lent value > lifetime won't extend its lender's. Does this already prevent refcou

Why `!=` is template and not a func?

Good idea, I am trying to find an example when it does not work with typed

Usability of ARC/ORC in multi threaded code.

It's true, that example isn't a real word example. This was simply me trying different things to figure out where it broke, and then being surprised when it broke even if I didn't use the argument. The point is that right now `isolate` is so strict it's not useful at all. Since you can't pass in

Usability of ARC/ORC in multi threaded code.

Maybe what you say is true, maybe not. In your example proc createTree(hello: Test): Tree = Tree(left: Branch(data: "Hello"), right: Branch(data: "world")) Run The parameter `hello` is unused. This means it's not a realistic example. I keep asking for realis

Atomic ARC

My monstrous Intel(R) Pentium(R) CPU N3710 on GNU/Linux: * atomicArc: 1. 33.883s; 490.574MiB 2. 32.888s; 490.422MiB * arc: 1. 33.686s; 490.379MiB 2. 32.808s; 490.566MiB

Atomic ARC

Swanky CPU here, 250% slowdown 16s vs. 40s on a POWER9 server, ran it 3 times each and results were ±1s

Why `!=` is template and not a func?

Intermediate summary 1. It is for inline 2. Another idea: not one promised that == result is bool, it can explain untyped result The only question left for me - why params are untyped?

Atomic ARC

AMD Ryzen 7 3700X arc: 166803 lines; 5.829s; 490.867MiB peakmem atomicArc: 166803 lines; 5.878s; 490.758MiB peakmem;

Atomic ARC

Intel i7-4770K koch boot -d:release --threads:on --mm:arc iter1: 8.505s; 612.438MiB peakmem iter2: 7.641s; 490.723MiB peakmem ./koch boot -d:release --threads:on --mm:atomicArc 6.896s; 490.719MiB peakmem 7.854s; 490.719MiB peakmem Run

Why `!=` is template and not a func?

> What is the real reason for it? to show off the language feature ;)

Atomic ARC

Intel i7-12700 koch boot -d:release --threads:on --mm:arc iter1: 4.176s; 490.711MiB peakmem iter2: 3.507s; 490.711MiB peakmem koch boot -d:release --threads:on --mm:atomicArc iter1: 3.528s; 490.676MiB peakmem iter2: 4.158s; 490.680MiB peakmem

Is it bug of pragma nodecl?

See

Why `!=` is template and not a func?

I think that it is about "the only idea" I wrote in initial message. It is good reason, but not obvious from the book/manual Another question is untyped

Atomic ARC

The problem is that suddenly you want to pass an object from a library between threads, and it uses `ref`. So now you can't pass that between threads simply because the original library owner didn't use `aref`?

Why `!=` is template and not a func?

I think that inline proc would do exactly the same. I know that inline is not strict. So, does the inline the answer? func is also not bad - I mean that its definition sometimes is better to read than template

Why `!=` is template and not a func?

Well inline proc is simply a hint to the C compiler, which is free to ignore it. So why rely on that when Nim has a perfectly good way of doing it itself? func has the same issue as proc, it's an extra call, and calls are "expensive".

Why `!=` is template and not a func?

Hello, Reading Nim's book I see that `!=` is template, which seems simple, but it is still not clear why it was prefered over func. 1. Why is it template? 2. Why it has untyped params. Why does it return expr but not bool? The only idea I have is from the not obvious template feature - th

Why `!=` is template and not a func?

AFAIK the default `!=` template simply expands to `not (x == y)`. This means that it doesn't do anything but a simple transformation. A proc here would (if it wasn't optimized by your C compiler) lead to an extra function call, which is much more expensive than simply rewriting something at comp

Atomic ARC

I would vote for this, but `aref` instead

Atomic ARC

> shared ownership is heavily discouraged and it's a pain to debug [Rant] Worst CPU owner here. TBH, debugging Nim code is PITA, with or without atomicArc. Recently I've tried to write an utility in Nim. I'm a hobbyist, an old one. I make a lot of mistakes during prototyping and I often get lost

Question from a complete Newbie

Thank you both for your help. I now see how I misunderstood the docs. Your help is much appreciated!

Usability of ARC/ORC in multi threaded code.

Hmm, this "solution" considerably lowers the usability of the isolation system though.. Even the original issue just calls for better alias detection. If we had better alias detection the first of my two usecases would be possible today. With the rules changes to an `and` I think the isolation s

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

You can also just declare your proc in Nim, ensure you have {.push stackTrace:off.} around it like here: proc MP4E_open( sequential_mod_flag: cint, enable_fragmen

Atomic ARC

maybe we can have `type Foo = ref object` and `type Foo = atomicRef object`? In general, shared ownership is heavily discouraged and it's a pain to debug. Being able to easily grep which objects might have shared ownership is a huge boon. And for example the Go language heavily emphasize produc

bug (?) with nested templates in generic proc

Here is a nice one: This doesn't compile proc foo*(s:openarray): auto = discard # Error: invalid type: 'T' in this context: 'proc (s: openArray): untyped' Run This compiles: proc foo*(s:openarray, N: static[int] = 0): auto = discard

bug (?) with nested templates in generic proc

Wow. Amazing. we need a wiki full of these tricks, or something more searchable than this forum. I'd upvote both q and a on stackoverflow if someone wants some free karma

Atomic ARC

Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (Windows 10 x64): `koch.exe boot -d:release --threads:on --mm:arc`: * iteration 1: 20.404s; 489.047MiB peakmem; * iteration 2: 15.703s; 489.32MiB peakmem; * iteration 3: 14.948s; 489.32MiB peakmem; `koch.exe boot -d:release --threads:on --mm:atomic

Is it bug of pragma nodecl?

You only asked for stack allocation of arrays which is what Nim does out of the box. It doesn't use direct braced initialization because back then C did not have this feature. If Nim's way with copyMem is better or worse, I don't know but we can look at the produced assembler to see that.

Is it bug of pragma nodecl?

The code `var x: array[6, char] = ['h', 'e', 'l', 'l', 'o', '\0']` doesn't work either. Here is the generated c code: static NIM_CONST tyArray__9bPFPkkEEeeNM9bKgiV8Q49cg TM__7Wo7NjlPCKzJJsFsMhIJow_2 = {104, 101, 108, 108, 111, 0} ; .. N_LIB_PRIVATE N_NIMCALL(void, main__

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 It was done to fix and a better alias analysis might have achieved the same.

Is it bug of pragma nodecl?

Why not use `var x: array[6, char] = ['h', 'e', 'l', 'l', 'o', '\0']`, Nim does allocate arrays on the stack just like C. To answer your question, it's a quirk that `.nodecl` doesn't work for local variables iirc. So you need to use: let x {.importc, nodecl.}: cstring proc