Re: [fonc] Final STEP progress report?

2013-01-23 Thread Craig Latta

 Sliding deadlines very often allow other pursuits to creep in ...

 With ellipses on their tiny feet! :)


-C

--
Craig Latta
www.netjam.org/resume
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] deriving a POL from existing code

2013-01-23 Thread BGB

On 1/9/2013 11:53 AM, David Barbour wrote:


On Wed, Jan 9, 2013 at 9:37 AM, John Carlson yottz...@gmail.com 
mailto:yottz...@gmail.com wrote:


I've been collecting references to game POLs on:
http://en.wikipedia.org/wiki/Domain-specific_entertainment_language


That's neat. I'll definitely peruse.



interesting...


my own language may loosely fit in there, being mostly developed in 
conjunction with a 3D engine, and not particularly intended for 
general-purpose programming tasks...


like, beyond just ripping off JS and AS3 and similar, has some amount of 
specialized constructs mostly for 3D game related stuff (like 
vector-math and similar).


well, and some just plain obscure stuff, ...


BTW: recently (mostly over the past few days), I went and wrote a 
simplistic JIT for the thing (I have not otherwise had a working JIT for 
several years).


it turns out if one factors out most of the hard-parts in advance, 
writing a JIT isn't actually all that difficult (*1).


in my case it gave an approx 20x speedup, bringing it from around 60x 
slower than C with (plain C) threaded code, to around 3x slower than C, 
or at least for my selection-sort test and similar... (the recursive 
Fibonacci test is still fairly slow though, at around 240x slower than 
C). as-is, it mostly just directly compiles a few misc things, like 
arithmetic operators and variable loads/stores and similar, leaving most 
everything else as call-threaded code (where the ASM code mostly just 
directly calls C functions to carry out operations).


in the selection sort test, the goal is basically to sort an array using 
selection sort. for a 64k element array, this is currently about 15s for 
C, and around 49s for BS. with the interpreter, this operation takes 
takes a good number of minutes.



*1:
current JIT, 1.2 kloc;
rest of core interpreter, 18 kloc;
rest of script interpreter (parser, front-end bytecode compiler, ...), 
32 kloc;
VM runtime (dynamic typesystem, OO facilities, C FFI, ...) + 
assembler/linker + GC: 291 kloc;

entire project, 1.32 Mloc.

so, yes, vs 291 kloc (or 1.32 Mloc), 1.2 kloc looks pretty small.

language rankings in project (excluding tools) by total kloc:
C (1.32 Mloc), BGBScript (16.33 kloc), C++ (16.29 kloc).

there may be some amount more script-code embedded in data files or 
procedurally generated, but this is harder to measure.



or such...

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc