Given that Nim compiles to C, then a C compiler compiles the resulting code, I
always find these faster-than-C benchmark claims slightly amusing ;)
I'd venture ahead and say that it's mostly the skill of the developer and not
so much the language that determines performance, by and large - that
hello, i'm trying compile urho3d with nim for very long time, but cant do it. i
tried compile it with mingw, with tdm-g++, with vs2019, with g++ on linux, but
nothing compiles. i have this code:
{.emit: """#include
#include
#include
using namespace Urho3D;
It seems to be obvious that in your approach the problem is, that split
iterator allocates a new string for each call. There may exist other, faster
but uglier solutions. Basically reusing the same string. Was that available in
parseutils? I can not remember, but I guess faster examples may be
Here you may find some pointers:
[https://forum.nim-lang.org/t/4731](https://forum.nim-lang.org/t/4731)
Thank you for your response. I'm jealous of your code ;-) Going to try and see
if I can implement something like that. I see you are using a never ending loop.
Thanks :D
> So can one beat the c version?
Long time ago I concluded that when it comes to optimizations, I can optimize
all day and night, but then at some point @mratsim will come and will improve
it by 50+% :D
So if you want to beat C, basically wait for @mratsim to show up and do his
magic :)
Hi,
fefe (a german blogger, [http://blog.fefe.de](http://blog.fefe.de)/ ) has
called for a little benchmark. The challenge is to count words in an webserver
logfile (from stdin), then output them ordered like so:
150 foobaa
80 faa
12 www
Run
Blog entries:
@nimpython, your example works fine using python 3.6. Perhaps you are using
python 2?
Still not quite understanding it, but it did go away when I changed the `style`
argument in
method set_style*(b:BaseButton, style:Table) {.base.} = assert(false,
"BaseButton.set_style() to override.")
Run
from `Table` to
method
It means you use both runtime and compiletime polymorphism at the same time and
that doesn't work well in Nim (and not well in other languages either) and you
should likely rethink your design a little bit.
Thanks, that was helpful, for anyone interested here how my macro looks like:
macro act(body: untyped): untyped =
result = nnkObjConstr.newTree(ident"ActivationFunction")
let flType = ident"NeuralFloat"
expectLen(body, 2)
for fn in body:
I'm getting some warning on some methods saying `generic method not attachable
to object type is deprecated`
What does that mean?
activations:
let sigmoid* = act:
fn: 1 / (1 + exp(-x))
deriv: fx * (1 - fx)
let tanh* = act:
fn: tanh(x)
deriv: (let t = tanh(fx); 1 - t * t)
Run
14 matches
Mail list logo
