> 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 
lexical scope.

Here are 
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 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to