Hmm... I confirm what I said. In a silly benchmark involving fibonacci, prime numbers and factorial (only real world examples as you can see ;), mzscheme took about 1mn35s and Arc (with fast numerical operations) only 58s. No doubt time is not broken as I used the Unix command this time. It also means that these 58s. include the 3s. on Arc startup. The actual time is closer to 55 s. No, if anyone has an idea about why a given code can be faster in Arc...
When I did the earlier Fibonacci benchmarking, I found it useful to take the code generated by ac, and run it inside mzscheme. (Note that :a will drop you from Arc to Scheme.) That is, running the exact same code that Arc does, just from the Scheme REPL. (This should take the same time as running in Arc, or else something is very wrong.) Then I could tweak the code a function at a time evolving from the Arc-generated code to the Scheme code, and see where the time was going.
Overall, it makes no sense that Arc would be faster. But it would be very interesting to find out why you're getting those results. Could there be some subtle algorithm difference, maybe lack of tail recursion, in the Scheme version?
Ok, I tried that. Running the fib code in a mzscheme REPL is slower than in an Arc REPL. But, if once in Arc REPL you type :a (and get to the mzscheme REPL with Arc functions loaded), the same Scheme code is then a little faster than the Arc counterpart. That means there is something in ac.scm that speeds up mzscheme computations. Maybe the fact that it's embedded in a module ? I really don't know, but at least this is not an aberration anymore.
I really don't know. It just is... It might be a bug in the time function, or for some reason the ugly code produced by the ac function gets optimized better than the simple mzscheme code...
Anyway, that's only a micro-benchmark. I'm trying to confirm this with more tests... I guess mzscheme will eventually be slightly faster than Arc.
It can be intersting if you want to have access to all the Java libs (that's one of the ideas of Clojure or Scala for example) and / or if you want to be able to be embedded in a client JVM (e.g. to write Scheme applets or sandboxed code). The latter cannot be solved by a JNI / FFI solution.
Well, the good thing with multiple choice polls is that you can give many answers. If you are born in Russia, spent most of your life in Canada and now live in Bamako, I think it can be interesting for Russian, Canadian and African people.
Well, the library extension is added automatically to the generated file by mzscheme. A .so is added on Unix systems, a .dll on Windows. The solution would be to change the compilation command in ffi.arc : it's something like "gcc -O3 --shared -o foo.so foo.c". Just change it to foo.dll and it might be working. I don't know how to automate this however. If someone has an idea...
The funny thing is that I wrote FFI for one reason besides optimization : I wanted a POSIX interface, so as not to rely on the system function, which is as broken as any shell script.
Imagine you make a script to remove all files ending with a ~ as they are backup files : foo.tex~, bar.c~ and so on. Now imagine your stupid user named a file ~. Guess what happens if you call "rm -r $file" in your script. It also works with files starting with - and many other funny things.
We could do something akin to Ruby: declare that "?", specifically, is allowed the end of an identifier. This seems to be as good a use as any, and it could still be used as a prefix or infix syntactic character.
Is there a standard graceful way of stopping a background process?
I could: launch nsv as a thread in the background, then fg it back, then use (quit) in the repl. But is there a better way to do this? Does (quit) shut down the server gracefully?
upon further reading through the forum, i figured out that the timeouts were a side-effect of the 'date problem' but because i hadn't been quick on the uptake, i had no idea that was what i was even looking for.
moving to anarki/arc-wiki stable fixed that. thanks for putting up with me, everyone!! :)
you are my hero, i hadn't seen the thread procedure documented in the tutorial.
the problem manifests itself as either 502 errors (served via mod_proxy_balancer) or "server dropped the connection" errors, but the thread business helps immensely.
There is another optional parameter to cdef : a finalization function. This function is called when the object return by the imported function is GCed. That way, you've got C and garbage collection :
(cdef zeros "zeros" cptr (cint cint) del)
In the above, del is called on objects returned by zeros once they are collected.
The sad thing is that, if memory is allocated on the C side, Arc can't know it. If you define (zeros 5000 5000), you eat 200 MB. You can run out of memory before the GC thinks "Hey, let's clean up !"
