> > 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 <https://github.com/mrakgr/The-Spiral-Language/blob/a7db1092d11a8d8820f8ee5c353683d7375a7e11/Learning/Modules.fs'#L475> 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 dimensions. 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 problem. 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.
