Re: Perfecting Nim

2018-04-29 Thread didlybom
> @didlybom The names follow 
> [https://nim-lang.org/docs/apis.html](https://nim-lang.org/docs/apis.html) (a 
> document that is not well known). initT is used for value-based types, newT 
> for pointer-based types. newSeq and newString depart from it because they 
> were created early on.

Thanks for the explanation @araq. The problem is that seqs and strings are 
likely to be the very first kind of thing that a new user is going to create. 
The fact that those two deviate from the general rule makes the rule hard to 
understand, IMHO. What good is a rule that is not applicable to the most common 
use case?

Wouldn't it make sense to define "initSeq" and "initString" procedures? It 
those were then used in the tutorials and the documentation it would help new 
users learn the rule you mentioned. Ideally the existing newSeq and newString 
could be marked as deprecated as well, but I do not know if that would be 
feasible given that it would basically make almost 
_[all](https://forum.nim-lang.org/postActivity.xml#all) existing nim code 
deprecated. 


Re: Optimizing Nim algorithm (compete with c++)

2018-04-29 Thread Araq
> I've been told recently that using main is not required anymore, i.e. there 
> shouldn't be speed/optimization differences if you use main or not. > Can 
> somebody comment on this?

It's still required but we could make the compiler do this transformation for 
us. However, there are much more important issues left, as usual.


Re: Perfecting Nim

2018-04-29 Thread Vantage
performant code when you want -> sane/safe/easy defaults 


Re: Optimizing Nim algorithm (compete with c++)

2018-04-29 Thread def
-d:release causes -O3 -fno-strict-aliasing. See config/nim.cfg or 
nimcache/app.c| 


Re: Optimizing Nim algorithm (compete with c++)

2018-04-29 Thread peheje
Thank you for the gist. You corrected some of my brainfarts as well.

Clang seems to be faster for me than gcc! Now faster than my cpp 
implementation. What configurations sets gcc as standard when compiling Nim?

My results: Clang: 0m0.144s GCC: 0m0.197s

I'm on a MBP 2013 with Core i7 I7-4850HQ.

clang --version: Apple LLVM version 9.1.0 (clang-902.0.39.1)


Re: Optimizing Nim algorithm (compete with c++)

2018-04-29 Thread miran
> Always use a `main` proc in Nim.
> 
> \
> 
> I noticed in another thread 
> ([https://forum.nim-lang.org/t/1268/1#7848](https://forum.nim-lang.org/t/1268/1#7848))
>  Araq telling to wrap the code in a main proc.

That thread is 3 years old. I've been told recently that using `main` is not 
required anymore, i.e. there shouldn't be speed/optimization differences if you 
use `main` or not.

Can somebody comment on this?


Re: Optimizing Nim algorithm (compete with c++)

2018-04-29 Thread def
Yes, wrapped everything in main: 
[https://gist.github.com/def-/4e4dea8f0f40ef7a77a2729148d8fe0e](https://gist.github.com/def-/4e4dea8f0f40ef7a77a2729148d8fe0e)

You could try a more recent GCC version (7.3.1 here). `nim -d:release 
--gcc.options.speed="-Ofast -flto -fno-strict-aliasing -ffast-math" 
--gcc.options.linker="-flto" c app` but measure which actually make a 
difference, if any.

I get 0.08 - 0.12 s with `nim --cc:clang -d:release 
--clang.options.speed="-Ofast -flto -fno-strict-aliasing -ffast-math" 
--clang.options.linker="-flto" c app` using Clang 6.0.0.


Re: Optimizing Nim algorithm (compete with c++)

2018-04-29 Thread peheje
Hi def You beat me to it!

**Thank you** very much for looking into it and replying. You are right!

I don't get quite the same performance boost as you do, cpp still seems faster 
but barely. Might be any number of reasons.

Do you have any more nice tricks for the nim code? Did you also wrap the 
constants and the xoroshift variables inside the main proc?


Re: Optimizing Nim algorithm (compete with c++)

2018-04-29 Thread peheje
Okay. I noticed in another thread 
([https://forum.nim-lang.org/t/1268/1#7848](https://forum.nim-lang.org/t/1268/1#7848))
 Araq telling to wrap the code in a main proc.

I did and now the speed is almost comparable to my cpp!

Nim: 0m0.197s cpp 0m0.159s

Impressive. I updated the master branch


Re: Optimizing Nim algorithm (compete with c++)

2018-04-29 Thread def
Always use a `main` proc in Nim. Speeds up the execution from 0.80 s to 0.15 s 
in this case for me, compared to 0.20 s for the C++ version (compiled with `g++ 
-Ofast -flto -o main main.cpp ArrayHelpers.cpp NeuralNetwork.cpp 
OptimizationProblems.cpp RandomGenerators.cpp`). You can also use `int32` 
instead of `int`, but doesn't have a huge effect here.


Optimizing Nim algorithm (compete with c++)

2018-04-29 Thread peheje
I have written a differential evolution algorithm in cpp and Nim.

My cpp version is faster (6-8 times) and I was hoping I could get comparable 
performance with the Nim implementation. I need a hand.

Nim version: 
[https://github.com/peheje/nim_genetic/blob/master/DifferentialEvolution/app.nim](https://github.com/peheje/nim_genetic/blob/master/DifferentialEvolution/app.nim)
 Compiling with nim compile -d:release app.nim

cpp version: 
[https://github.com/peheje/differential_evolution_cpp/blob/master/differential_evolution/main.cpp](https://github.com/peheje/differential_evolution_cpp/blob/master/differential_evolution/main.cpp)
 Compiling with -Ofast and Link Time optimization: Monolithic in XCode.

When I run the Nim profiler it seem something called **system.nim: 
genericReset** is time consuming, what is this?

Entry: 1/6 Calls: 14/52 = 26.92% [sum: 14; 14/52 = 26.92%]
system.nim: app 52/52 = 100.00%
Entry: 2/6 Calls: 13/52 = 25.00% [sum: 27; 27/52 = 51.92%]
system.nim: genericReset 25/52 = 48.08% app.nim: app 52/52 = 100.00%
Entry: 3/6 Calls: 12/52 = 23.08% [sum: 39; 39/52 = 75.00%]
assign.nim: genericReset 25/52 = 48.08% assign.nim: genericReset 25/52 = 
48.08% system.nim: app 52/52 = 100.00%
Entry: 4/6 Calls: 5/52 = 9.62% [sum: 44; 44/52 = 84.62%]
app.nim: f_rand 5/52 = 9.62% app.nim: app 52/52 = 100.00%
Entry: 5/6 Calls: 4/52 = 7.69% [sum: 48; 48/52 = 92.31%]
app.nim: i_rand 8/52 = 15.38% app.nim: app 52/52 = 100.00%
Entry: 6/6 Calls: 4/52 = 7.69% [sum: 52; 52/52 = 100.00%]
app.nim: xor128 4/52 = 7.69% app.nim: i_rand 8/52 = 15.38% app.nim: app 
52/52 = 100.00%

I have not used the random library. I think it is the strategy to make 
xoroshift unbiased with the while loop is slowing it 
([https://github.com/nim-lang/Nim/blob/2a8d2ad4cde1c942a9dbc44598f65d4acf1e0aa6/lib/pure/random.nim#L77](https://github.com/nim-lang/Nim/blob/2a8d2ad4cde1c942a9dbc44598f65d4acf1e0aa6/lib/pure/random.nim#L77))
 and my application don't care much about the bias introduced. 


Re: Perfecting Nim

2018-04-29 Thread DTxplorer
@Allin I didn't find basic2d and basic3d, in the docs the links are dead.


Re: Perfecting Nim

2018-04-29 Thread slangmgh
I like the idea to make `seq` and `string` default `@[]` and `""`, we can use 
`{.noinit.}` to make them `nil` if care about performance.


changing the order in which checking for functions

2018-04-29 Thread Vantage
If you first make a mini-header file then define the functions wouldn't that 
ensure that you can call a function defined below the another function


proc foo()=
bar()
  proc bar()=
discard 1+1
  foo()


the code above would result in an error


  cannot find bar()


Maybe a preprocessor or some change of ordering of reading the module would be 
better 


### auto generated 
  proc foo()=
  proc bar()=
  ###
  proc foo()=
bar()
  proc bar()=
discard 1+1
  foo()


This is a suggestion. I don't really expect anyone to implement it but I think 
it'd be a good addition.


Re: Statistics for standard library usage

2018-04-29 Thread twetzel59
Very interesting!


Statistics for standard library usage

2018-04-29 Thread GULPF
Since there's been some take about reducing the standard library, and because I 
was curious, I decided to generate some statistics for usage of the standard 
library in GitHub projects. I used the top 1000 most starred Nim projects on 
GitHub.

* * *

**Results:** 
[https://gist.github.com/GULPF/6d49e74af9992f8fc65476a9264488a0](https://gist.github.com/GULPF/6d49e74af9992f8fc65476a9264488a0)

Some observations:

  * `re` is used significantly more than `nre`
  * `parseopt` is used more than `parseopt2`
  * About ~25% of the projects use the `macros` module
  * `posix` is used about twice as much as `winlean` (not surprising)



Note: I based the list of stdlib modules on 
[this](https://nim-lang.org/docs/theindex.html) listing, which includes some 
modules that are not listed on the main documentation page.