> Can you please elaborate on that? I looked into your code and since you're
> using intrinsics you're dependant on the mercy of the compiler to schedule
> everything right, is the assembler code you're talking about worse than what
> the compiler archieves? Or do you use some faster algorithm t
> For example my SIMD definition for SSE2 and AVX512 mtrix multiplication which
> allows me, in thousand of lines of Nim code to be as fast as 50x more pure
> assembly lines in OpenBLAS
Can you please elaborate on that? I looked into your code and since you're
using intrinsics you're dependant
Regarding SIMD, you have the same challenges as C or C++ in Nim.
You can use GCC/Clang builtin vector types for example
{.emit:"typedef float Float32x8 __attribute__ ((vector_size (32)));".}
type Float32x8 {.importc, bycopy.} = object
raw: array[8, float32]
Thank you very much for your suggestions, they were useful. My amendments,
comments or otherwise:
> "Consider a naive implementation of a .* operator to add two sequences
> together:" -> to multiply two sequences
This is correction is already done - maybe refresh your browser. I usually
refres
Couple of things after skimming through it:
* "Consider a naive implementation of a .* operator to add two sequences
together:" -> to multiply two sequences
* in the equation for polynomial kernel use `\text{Offset}`
* personally would not define `var ret` and use `return ret`. Instead use
> No seqs are not reference types, they copy on assignment. If you need ref
> semantics you would use ref seq[T].
When I first wrote that both arrays and sequences were value types in Nim I was
fairly sure but then I haven't written Nim in a little while and, to be fair
when I made the wrong am
> You mean "compute the dot product"? That seems to be what that operation
> actually does in the example beneath it.
Thanks for spotting the mistake, not the dot product but just a simple element
by element multiplication . It shows you can easily create operator similar to
that in Julia's ele
No seqs are not reference types, they copy on assignment. If you need ref
semantics you would use `ref seq[T]`.
> This is not true, sequences are reference types
My understanding is that the "top-level" structure of a sequence is a value
object (also containing length and capacity), but the structure contains a
reference to the actual seq data on the heap.
Has this changed?
The dimensions of a matrix often aren't known at compile time.
> Consider a naive implementation of a `.*` operator to add two sequences
> together:
You mean "compute the dot product"? That seems to be what that operation
actually does in the example beneath it.
> Both arrays and sequences in Nim are value rather than reference types.
>
> This is not true, sequences are reference types, id suggest you to:
>
> 1st. Correct this.
Corrected. Thanks
> 2nd. Use an array instead of a seq, something like this maybe: ...
Using sequences serves two purposes, i
Why didnt you use an array instead of a sequence?
Thanks for letting me know. I've updated the link now.
I get a 404
Hi All,
I just finished a breif article on programming in Nim demonstrating it using
Kernel Matrix calculations
(<https://www.active-analytics.com/blog/kernel-matrix-calculation-in-nim/)>.
It's live, but I wanted to get the opinion of the Nim community on its fairness
and accur
16 matches
Mail list logo
