> What is the backend for Spiral -- a combination of the CPU and a GPU?
Yeah. The main one is the F# one, but it is easy to write Cuda kernels as
well. In fact, much easier than in C++ since they can capture values in
all of them that I've written so far. They look quite nice right?
Everything in that module in fact works and feedforward nets are not a
problem for the library. Spiral's tensors make indexing much simpler than
in C++ and they are generic in the type, layout and the numbers of
The two backends are like 500 lines of code each so it would not be a
problem to add more should the need arise.
The standard way of implementing a Racket language X is to parse and
> compile/expand a source file into an existing Racket language (which
> eventually will be compiled to bytecode and then jitted). If one takes care
> to keep source locations around, IDE integration will be automatic.
This approach (the compiled source uses Racket primitives) will allocate
> values on the standard heap and use the built-in garbage collector in
> Racket. It is possible to use low-level primitives to allocate memory that
> the Garbage collector won't touch though. See "Inside: Racket C API".
Would it be possible for Racket to save the results of a partial macro
expansion, such as for an optimization pass to a file without me having to
define a custom file format and serialization functions? That would save me
a lot of work. Right now Spiral is slow due to having to parse and optimize
the standard library on each iteration.
The reason why I am asking for an extensible GC is because GCs can do
things like compact the memory and trigger when it is getting low.
The most I can get with .NET at the moment would be its safe handles. They
act as wrappers around unmanaged resources, but my sense is that they won't
be enough to let me manage GPU memory because they cannot do any of the
above, at most they can act as safeguards. I also would not mind if the GPU
GC tracked resources separately from the rest as I'd want to trigger it
after every NN pass because that is the point where memory should be freed
in bulk in most cases and I do not want it to go over the entire working
set...though if it did I suppose it would not be a problem given how little
heap allocation Spiral actually does at runtime.
Basically, I want GC, I want to tune it for my specific need and I want to
tune it for Spiral's strengths. Spiral is not a dynamically typed language,
but a statically typed one with intensional polymorphism and first class
staging which might offer some interesting avenues of approaching the
Well, another problem I have is with the language's compiler which is not
necessarily slow, but the issue is that I have no idea how fast it is
relative to what could be. The .NET profiler is useless and keeps showing
me broken stacks due to all the tail recursion thereby making bottom up
analysis useless. I suppose you wouldn't know without experience at both,
but does Racket have good facilities for optimizing compile times such as
during macro expansion? If I could get some indication that I could make
the compiler a lot faster by rewriting it in Racket that would be strong
motivator for me to do so.
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.