looks like original code was buggy indeed, could you send out a PR?
It might be a lot of things, but I'm telling you - there is a `gcc`
optimization, very finicky about context (and probably compiler flags, too),
that reduces function calls by almost exactly his speed-up factor. There's
really no need to guess if I'm right, though. Just add `-pg` to the gcc flag
Besides constant folding, there might be [code
alignment](https://dendibakh.github.io/blog/2018/01/18/Code_alignment_issues)
that can cause massive perf difference.
Alright, so after looking around a bit, I figured how to do it. It's not that
complicated, but for the sake of future readers, I will write it down here for
oh-my-zsh:
1. install zsh completions as detailed in
[https://github.com/zsh-users/zsh-completions](https://github.com/zsh-users/zsh-com
Thank you!
this does work:
>
> type
> Data*[T] = object
> contents: T
> subscribers: seq[proc(d: T)]
>
> proc createData*[T](t: typedesc[T], c: T): Data[T] =
> result = Data[T]()
> result.contents = c
> result.subscribers = @[]
>
> pr
No `gcc` doesn't -- at least not for me with a factor of about 7X, almost
identical to @adrianv 's results. I used both an earlier gcc-7 and a gcc-8.2
just now.
If you don't want to disassemble your binary, that's ok. You can check this
with `gcc -pg` and `gprof` which will count calls for you.
Nim doesn't evaluate fib(46), GCC does. And it doesn't get up to fib(46), it
evaluates up to fib(34) then does the remaining calculations at runtime. I'm
sure this exact same occurence was mentioned in an older thread.
proc addSubscriber*[T](d: var Data[T], cb: proc(d:T)) =
d.subscribers.add(cb)
Run
A typo `T` for `Data[T]`, and `var` needed for `add`.
I am not quite sure what "original" benchmark you mean - perhaps the 4.6 s for
Nim vs 6.0 s for C on the original github page at the top of this thread. That
may be small scale code layout/caching/branch predictor effects as you say.
However, the difference in this thread of 8X is _almost certai
Yes. Thats right. But its a dependency. My gui lib already depend upon winim.
At first my objects were like this - "control.property.text" But i have changed
that into this - "control.text"
Don't get overexcited. This is probably just a coincidence coming from the
random addresses of the compiled functions and branch instructions that affect
things like the branch prediction unit in the CPU.
I am close to being able to publish yet another graphical interface module for
nim. It will sit on top of oldwinapi or gtk2 and be philosophically similar to
iup. I am currently developing it (on Ubuntu) using a local GIT repository
which is in my working directory and pushing versions of the mo
Thanks to all contributors !
A new version of [Nim basics](https://narimiran.github.io/nim-basics) tutorial
is out.
It uses Nim 0.19.0, meaning sequences and strings are automatically initialized
so we don't have to do it explicitly. (But there is a note for users of older
Nim versions)
And if you haven't seen it in the l
> If Nim compiles to C Nim is not faster than C but Nim is able to produce
> faster C code than human programmers.
Effectively making it faster than C ;)
Thankyou for your reply @mratsim
I tried the following:
type
Data*[T] = object
id: string
contents: T
subscribers: seq[proc(d: T)]
proc addSubscriber*[T](d: T, cb: proc(d:T)) =
d.subscribers.add(cb)
proc c
I also got `nim c` 's code running twice as fast as `nim cpp` 's code. See some
previous discussion:
[https://forum.nim-lang.org/t/1779](https://forum.nim-lang.org/t/1779) \- there
are cases where Nim's generated C code "inspires" the C compiler to "unroll the
last few recursions" and save 4x o
On my end `nim cpp` is twice _slower_ than `nim c`.
Oh and btw, whichever version of code you use — the result is not correct ;)
Try running `fib(2)` and you'll see what I'm talking about.
Hi y'all,
I see in the codebase that there is an auto-completion feature for zsh, but it
doesn't seem to automagically work after installing nim through Solus's package
manager:
sudo eopkg install nim
Run
(with eopkg being the standard package manager on Solus, cfr.
If Nim compiles to C Nim is not faster to C but Nim may produce faster C code
than human programmers.
I think this was posted a while ago and the answer was that G++ found a way to
constant fold Nim's C++ output. This means it probably evaluated fib(46) before
the program ever ran. A bit disappointing, sure, but the C output benchmark is
still very good.
Hi, on twitter I saw that Nim performed better on fibonacci benchmark than C
and C++ ([https://github.com/drujensen/fib](https://github.com/drujensen/fib))
and wondered why. I did my own tests and these are quite interesting:Language|
Time in s| compiled with
---|---|---
Nim| 0.456| nim cpp
That was something that was in the manual as coming soon for about eight months
before being removed:
[https://github.com/nim-lang/Nim/commit/c671356d51488c96b4749a4d109b00d924e1f739](https://github.com/nim-lang/Nim/commit/c671356d51488c96b4749a4d109b00d924e1f739)
This should still be happening
Yes you can, see this for example:
[https://github.com/mratsim/nim-rmad/blob/master/src/autograd.nim#L46-L57](https://github.com/mratsim/nim-rmad/blob/master/src/autograd.nim#L46-L57)
Note that the proc arity (number of arguments) is part of the type, as is its
calling convention (pointer/{.nimc
24 matches
Mail list logo
