Re: Faster and Safer Raytracing in Nim
@mratsim, I agree with @aredirect: this repository of yours is pure gold!
Re: Performance issues with "complex" module
Awesome @Stefan_Salewski, that worked perfectly! Thanks a lot!
Performance issues with "complex" module
I ran a few benchmarks of C++, Julia, and Nim compilers, and I found that Nim's
implementation of Complex64 type shows sub-optimal performance.
I have implemented a simple algorithm to compute a [Julia
set](https://en.wikipedia.org/wiki/Julia_set) , and I have found that the
simplest implementation is quite slow:
import complex
func julia(z: Complex64, c: Complex64, maxiter: int = 256): int =
var iteridx = 0
var cur_z = z
while (abs2(cur_z) < 4) and (iteridx < maxiter):
cur_z = cur_z * cur_z + c
iteridx += 1
result = if iteridx == maxiter:
-1
else:
iteridx
Run
Generating a 800x800 image requires 1.5 s on my laptop, to be compared with
~0.07 s for an almost identical code in Julia (note the pun!). Inspecting the C
code produced by Nim shows that the compiler is not trying to inline the call
to functions like
[*](https://github.com/nim-lang/Nim/blob/version-1-2/lib/pure/complex.nim#L122).
So I changed the computation within the `while` loop in this way:
# cur_z = cur_z * cur_z + c
cur_z *= cur_z
cur_z += c
Run
The elapsed time went down to ~1 s: better, but still not good! My
understanding is that this modification helps the compiler to avoid the
creation of some temporary Complex64 variables.
Then, I decided to manually unroll the computation of the real and imaginary
parts of `cur_z`:
# cur_z = cur_z * cur_z + c
let tmp = cur_z.re * cur_z.re - cur_z.im * cur_z.im
cur_z.im = 2 * cur_z.re * cur_z.im + c.im
cur_z.re = tmp + c.re
Run
The code is much uglier, but now the elapsed time is ~0.2 s!
At this point, I have a few questions:
1. Is there a way to further improve the code and reach Julia's speed (0.07
s)?
2. The last version of the code is surely the fastest, but it's really ugly
to read! Is there an _elegant_ way to keep the elapsed time down to ~0.1 while
avoiding the need to manually unroll the calculation of the real and imaginary
parts? (Maybe using `{.inline.}` everywhere in the complex module?)
The full code of the benchmark, as well as the command-line parameters I used
to compile it, can be found in this Gist:
[https://gist.github.com/ziotom78/346fff619dc093d473abfe4cb0b8060c](https://gist.github.com/ziotom78/346fff619dc093d473abfe4cb0b8060c)
Re: Nim programming book for kids
> We had a public library where I got many books, one was a nice Pascal book > which I loved. Was not able to find it again. Could it be [«Complete Turbo Pascal»](https://archive.org/details/completeturbopas00dunt), by Jeff Duntemann? This is the book I used to learn Pascal when I was a kid, and I felt in love with it!
Re: Nim for Statistics
Consider however that most of the work done by statisticians with data involves interactive sessions: lLoad the data, do some plots, combine columns, quickly compute a few estimators, redo the plots, etc. R and Julia have the advantage of being REPL-oriented and have good support for Jupyter, which means that this kind of workflow is somewhat natural. Statically-typed languages like C++ and Nim are perfect if you want to implement a data analysis pipeline whose blocks are already settled, but they are not great for interactive data exploration, where you do not know exactly what you are going to find in your data.
Re: Fortran bindings
I never tried to bind Fortran libraries to Nim, but I often have to deal with Fortran codes in my job. If you are lucky enough to work with Fortran 2003 or 2008, you can use `iso_c_binding`: [https://stackoverflow.com/tags/fortran-iso-c-binding/info](https://stackoverflow.com/tags/fortran-iso-c-binding/info) I think that the most useful example in that page is the one in Sect. 9 («Example of C calling Fortran»).
Re: Nim partners with Status.im
> I would love to see articles discussing these issues, but at the same time, I
> wonder if it's a good idea to bring more spotlight to style insensitivity.
Sorry, it has been a looong time since I posted here as I do no longer use Nim,
but… I always felt a bit "weak" to sell Nim's style insensitivity with the
argument that it is nice to pick the style you prefer. I consider the inability
to mix styles to be a far greater advantage; consider the following C code:
int Result = 0;
for (int i = 0; i < 100; i++) {
int result = f(x);
if (result < 0) {
result += g(x);
}
Result += result;
}
Run
This is an abridged version of some code I had to work on several years ago.
Such a mixture of styles would immediately trigger an error in Nim, as `Result`
and `result` are the same variable. (This is the same reason why I am a fan of
case insensitivity in variable names, like in good old Pascal.) The same would
apply if somebody tried to declare two variables `myAccum` and `my_accum` in
the same context.
When encouraging my colleagues to try Nim, I often found that this argument was
quite effective.
Re: Trouble with reading from stdin
I wasn't aware of this kind of limitation with standard input. Perhaps you can find some clues about how to fix this by having a look at the source code of [pv](http://www.ivarch.com/programs/pv.shtml). I often use it to process data read through stdin, and I have never encountered problems with large data files. Its source code seems very well written and easy to follow: [https://github.com/icetee/pv](https://github.com/icetee/pv)
Installation instructions on the website
Hi to everybody, Today I tried to install the latest stable version of Nim (0.15.2) on my Linux Mint system. I think I spotted a few problems in the documentation; I am reporting them here because it is not clear to me if the Nim's GitHub bugtracker is appropriate for this kind of issues. I followed the instructions on the [website](http://forum.nim-lang.org///nim-lang.org/download.html) («Installation based on generated C code»), which seems to be the preferred way to install Nim under Linux. I downloaded the tarball, unpacked it and compiled the `nim` executable. At this point, I was not able to create the executables for `nimble` and `nimsuggest`. The site says: > To build associated tools like `nimble` and `nimsuggest` run `nim c koch && > koch tools` However, the `koch` executable bundled with Nim 0.15.2 does not seem to support the `tools` command, as `koch tools` prints the help screen and exits. I turned to the Nim Documentation index, and I spotted the [paragraph](http://forum.nim-lang.org///nim-lang.org/docs/nimsuggest.html#installation) explaining how to install `nimsuggest`: cd compiler/nimsuggest nim c -d:release nimsuggest So I decided to follow this advice. However, the latter command returned the following error message: compiler/nimsuggest/nimsuggest.nim(12, 8) Error: This project has moved to the following repo: https://github.com/nim-lang/nimsuggest Ok, so I turned to the `nimsuggest` GitHub webpage, which says: > Starting with version 0.15.3, nimsuggest is part of the Nim repository again. > This is only used as an issue tracker. […] Nimsuggest is part of the Nim core > now, koch can build nimsuggest for you. So I am back to the start! With a little bit of effort I should be able to compile `nimble` and `nimsuggest` manually, as I used Nim quite a lot a few years ago. However, a novice user might get confused. (I would suggest to add some text/link at the bottom of each page on the website, which should explain what is the proper way to report errors/omissions/suggestions about the website itself. Should one post on the forum, like I am doing right now, or open a ticket on the bugtracker, or…?)
Re: Love nim but at the same time starting to hate it...
**moigagoo**, it was not hard at all. I used it for a couple of projects where I desperately needed some of sphinx' features (e.g., mathematical formulas). Since currently I am no longer using Nim for my projects, that repository is in a quiescent state. (I hope to use Nim again once version 1.0 is out.)
Re: Love nim but at the same time starting to hate it...
**moigagoo**, I once wrote a Sphinx extension for Nim. See here: [http://forum.nim-lang.org/t/678#3669](http://forum.nim-lang.org///forum.nim-lang.org/t/678#3669)
