Re: Fastest Prime Sieve, in Nim
@BLM2, I'm still working on this, but since comparing single threaded performance is like racing cars where each is limited to firing on only one cylinder when they have at least four and maybe six, eight, twelve, thirty-two or sixty-four: one can compare performance per cylinder but some cars and driving techniques may not scale across the different cars for this limitation. Anyway, even if one is going to compare this way, it should be on the basis of performance in CPU clock cycles per core-pair since HyperThreading (HT)/Simultaneous Multi Threading (SMT) thread pairs usually share L1 and L2 cache resources for modern CPU's. That is the problem with Dana Jacobsens's single threaded sieve comparison chart ([http://ntheory.org/sieves/benchmarks.html](http://ntheory.org/sieves/benchmarks.html)) although it is somewhat useful for comparison by scaling clock speeds as described below. The top contenders in her Chart are likely no longer the fastest, as Huang YuanBing's "ktprime" (K Tuple Prime) written in C ([https://github.com/ktprime/ktprime](https://github.com/ktprime/ktprime)) is actually up to about 10% faster than Kim Walish's "primesieve" when run single threaded producing 'k'=1 (the non-k) as one can determine by scaling his (single-threaded) 1e10 and 1e12 results on his i7-6700 CPU running at 3.9 Gigahertz with Dana Jacobsen's single threaded tests run on a i7-6700K CPU running at 4.2 Gigahertz. Unfortunately, Dana doesn't seem to see comparing single threaded results the way I do (or more likely she is comparing many algorithms that haven't been written to be multi-threaded) and "ktprime" hasn't yet had multi-threading added anyway, but I see no reason it wouldn't hold its lead over "primesieve" when multi-threading is added. The code for "ktprime" is much more complex than yours as it is more general in being able to be used to count/find "K-Tuple Primes" in the general case and not just Twin Primes as your code does and also part of the extra lines of code are due to it being written in C and not Nim and as well having a full command line interface rather than just the basics, but the general principles of using "PGX" wheel factorization generators are the same. Your trick of boiling down the performance by eliminating some sieving of residual bit planes that aren't required for Twin Primes will still beat it for that special case if the same optimizations were applied to your code as he uses, but that is very much a special case. Note that most newer algorithms don't even bother with sieving to a billion as that is now such a trivial case (about 40 milliseconds multi-threaded on a modern desktop) for modern algorithms and simple tricks that only work for these "smaller" sieving ranges can change the outcome but aren't generally applicable to larger ranges: thus, the comparisons should really start at ten billion or (even better) a hundred billion. For instance, "primesieve" runs about 20% faster sieving to a billion on a CPU with a 32 Kilobyte sieve buffer size than with a 16 Kilobyte sieve buffer size when run single threaded, but these gains don't translate to multi-threaded use as two threads share this same cache meaning that it effectively becomes about the same performance as if it were only 16 Kilobytes per thread. Also, the problem is that these better algorithms are too "grainy" at small ranges with possibly a single thread task sieving up to about a four billion number range at a time and a processor with eight threads thus processing a range of about 32 billion per step! What really counts in speed is the ability to sieve these larger ranges efficiently and in a way that scales well with multiple threads. Kim Walich's "primesieve" only scales moderately well with increasing range due to conflicting memory access HT/SMT threads sharing the same CPU L1 cache as described with "ktprimes" possibly scaling better and my own work where I always use just only half the L1 cache definitely scaling for multi-threads in a direct way. > ...and may finally try to do a C++, since people want to see a C++ version. I don't know that you need to go that far if you don't want to - I personally dislike C/C++ intensely and never write anything in them more than a couple of hundred lines of code, which is why I am with Nim: most people capable of reading and understanding C++ code should be able to easily translate your few hundred lines of Nim code and if it is just for the purposes of comparative benchmarks, it is a trivial task to install the Nim compiler that basically just generates C or C++ code from your code anyway. But "have at it" if you must and it will be an interesting exercise anyway in comparing the code. In my experience, Nim can run just as fast for the same algorithm as C/C++ as long as one pays attention to memory allocation as in not using the Garbage Collector (GC) and is aware of when deepCopy operations will be
Re: Procs that work only inplace like strutils.removeSuffix()
I kind of agree, have you seen `os.splitPath().tail` ?, but I dont really understand whats the question/problem if any... 樂
Re: What text editor are you using for Nim?
Unfortunately Kakoune is not available for Windows so that's not an option for many users. As for modal editors like vi being faster than Emacs...maybe, once you are in the right mode... but having to check what mode you are in all the time (even if you put mode changes on keys) will definitely slow you down.. initially ;-)
Re: What text editor are you using for Nim?
> In Vim I have to press Esc to come out of Insert mode then Shift-; to get : > then I have to enter w and finally press Enter then to carry on editing > text I have to press I again is that right Vim users? WTF! Ehm, no. You could just use the default shortcut: `ZQ` Or, if you want to save and exit: `ZZ` I personally used to use Vim, then Neovim and now I've been using kakoune for a few months because Neovim is getting bloated. [This is a very good explanation of why vi-like modal editors are superiors to "normal" editors like Emacs.](http://kakoune.org/why-kakoune/why-kakoune.html)
Re: What text editor are you using for Nim?
Yep, but I can also map Ctrl-x Ctrl-s to just Ctrl-s in Emacs if I wanted... but the default is fast enough... and Ctrl-s is mapped to search (another common editing task) anyway. And Emacs has macros that can be mapped to key strokes as well, so I cant see any Vim advantage there. Emacs Lisp is fairly easy to use to write custom tasks that can be added to a menu or key stroke as well, which is what I have done a few times. For example here is some Emacs that I have on my own menu that opens the Windows folder where the current file is: ;; Open the command window at current files directory ;; (defun neils-start-cmd () "Open the command window at current files directory" (interactive) (let ((proc (start-process "cmd" nil "cmd.exe" "/C" "start" "cmd.exe"))) (set-process-query-on-exit-flag proc nil))) ;;
Re: What text editor are you using for Nim?
You could map Ctrl-S to :w easily in your .vimrc But Space-W is faster, no holding any keys down Space rules as leader
Re: What text editor are you using for Nim?
yea, but you can just map Ctrl-S to save if you save so much. Typically vim keeps swap files and save the file state there periodically, so you don't have to keep saving the file as you type. If the editor crashes, you can re-open the file and the editor will ask to restore it. The power of the vim layout is editing speed versus emacs, in which commands and macros can be used in rapid succession to perform complex text manipulations in a couple of key strokes. If you really wanna try vim, you'd need to put in some effort (`vimtutor` can be useful to learn some tricks), but it'll be worth it :) (even emacs users know this, see `evil-mode`)
Re: What text editor are you using for Nim?
Here is an example of Vim v Emacs. Using default keys for both editors... Saving the current file. something we do quite often In Emacs I simply keep one finger on the Ctrl key and then press x followed by s... file saved continue editing text In Vim I have to press Esc to come out of Insert mode then Shift-; to get : then I have to enter w and finally press Enter then to carry on editing text I have to press I again is that right Vim users? WTF! No wonder I prefer Emacs :-)
Re: What text editor are you using for Nim?
As I said at start of this thread ive been using Emacs for the past few months and starting to get use to it... and ive just re-installed Vim to have another look... and No, I still don't like this... press Esc then press I for insert press Esc again blah blahcrazy... sometimes you start typing only to realise your not in Insert mode!! Mad... think ill stick with Emacs :-) Anyway... keep the editors coming :-)
Re: What text editor are you using for Nim?
> I tried textadept but the autocompletion feature seems a litte bit buggy; > notepad++ works fine but minimalistic; the intellij plugin seems not to be > maintained so I still stick with vscode… I tried Textadept myself a while back and didn't like it because as far as I know it was only 32 bit plus its Regular Expressions capabilities were severely lacking.
Procs that work only inplace like strutils.removeSuffix()
Often that may be OK, but not always. For removeSuffix() I have used
strutils.replace() sometimes as a substitute, but that is not always the best
solution.
So I was just thinking about other solutions. An apply template seems to work:
import strutils
template apply(x: typed; f: typed; par: typed): untyped =
var h = x
f(h, par)
h
const
Name = "manual.txt"
Doc = Name.replace(".txt") & ".html"
#Doc2 = Name.removeSuffix(".txt")
Doc3 = apply(Name, removeSuffix, ".txt")
Doc4 = Name.apply(removeSuffix, ".txt")
echo Doc
echo Doc3
echo Doc4
Run
manual.html
manual
manual
Run
Maybe there are even better solutions?
(Of course I understand why removeSuffix() works in place, while replace not:
The code of replace needs a temporary string as buffer, as the replacement can
be larger, so it makes sense to return that buffer. removeSuffix() can work in
place, so it does this. But sometimes a proc with result like suffixRemoved()
is what one wants.)
Re: What text editor are you using for Nim?
I use VSCode but as luck would have it this week I tried Howl, Micro and Neovim as well to find an alternative that exhaust less heat in my home? Unfortunately they don't come close to VSCode when working on 2/3 codebases at the same time (one with specs/tests, one with reference implementation, one you actually developing for example). I hope the VSCode plugin will get fixed and not spawn 1000s of nimsuggests (well know it kills them with a timer). Also I'm happy to see krux02 commit fixing nimsuggest / nim check hanging in macro: [https://github.com/nim-lang/Nim/pull/11849](https://github.com/nim-lang/Nim/pull/11849). As I spend so much time in macro land, that drains better/heats the home real fast.
Re: What text editor are you using for Nim?
I tried textadept but the autocompletion feature seems a litte bit buggy; notepad++ works fine but minimalistic; the intellij plugin seems not to be maintained so I still stick with vscode...
Re: db_mysql: how to get column name?
There is an overload to instantRows which takes a var seq[DbColumn] as in iterator instantRows*(db: DbConn; columns: var DbColumns; query: SqlQuery; args: varargs[string, `$`]): InstantRow = Run So you should be able to do something like: var cols : DbColumns = @[] for x in db.instantRows(cols, query): for idx, col in cols: echo col.name Run
