2014-07-29 00:35
ELLIOTTCABLE changed the topic of #elliottcable to: a
_better_ cult ˙ ͜ʟ˙ embrace, extend, extinguish.
00:24
<
gq >
i kind of miss when this place was called Hat.
00:50
oldskirt_ has joined #elliottcable
00:50
oldskirt_ has joined #elliottcable
00:52
oldskirt has quit [Ping timeout: 250 seconds]
01:05
Rusky has joined #elliottcable
02:03
oldskirt_ is now known as oldskirt
02:59
<
glowcoil >
gq: hee hee yes
03:06
<
gq >
right? so many good jokes.
03:10
<
devyn >
katlogic: my skills aren't quite at the level where I could sub anime… but it would be pretty cool to do
03:10
<
devyn >
katlogic: I did once upload a rare torrent
03:11
<
devyn >
and I seed rare torrents that I've leeched, of course
03:11
<
devyn >
does that count? ;)
04:14
Rusky has quit [Quit: Leaving.]
06:37
<
purr\Paws >
Paws.rs/master cba310a Devyn Cairns: Rust nightly: Share => Sync
06:40
<
purr >
<banisterfiend> you just struck me as a naruto kind of guy
06:40
<
purr >
gq: they're weird
08:12
eligrey has quit [Read error: Connection reset by peer]
08:51
gq has left #elliottcable [#elliottcable]
09:05
prophile has joined #elliottcable
10:43
gq has joined #elliottcable
11:04
* gq
curls up on purr & goes to sleep
11:10
<
Cheery >
katlogic: are you around?
11:10
<
Cheery >
katlogic: know any benchmark that would give a hint about the quality of implementation?
11:10
<
Cheery >
katlogic: I would like to test the snakelisp.
11:10
<
katlogic >
just port some of the debian shootout ones
11:10
<
katlogic >
i believe there are several lisps
11:11
<
Cheery >
there's the list of functions I've implemented. might help in selection
11:12
<
Cheery >
whatever can be implemented in those, or minor superset of those
11:12
<
katlogic >
feels mostly like lisp, minus the lists :)
11:12
<
Cheery >
minus the linked lists.
11:13
<
Cheery >
I can write up the benchmark, I'd just need to pick up the one that's rather generic.
11:13
<
Cheery >
allocate/deallocate probably doesn't fly. I don't have GC yet.
11:14
<
katlogic >
pidigits for math, probably
11:14
<
katlogic >
binary-trees for gc / attribute access
11:15
<
katlogic >
and then some not-so-microbenchmark if you want some real numbers, like deltablue (SAT solver, idiomatic OO)
11:17
<
Cheery >
is the deltablue hard to implement?
11:18
<
Cheery >
that seems about the simplest thing here.
11:20
<
Cheery >
deltablue doesn't look hard to implement!
11:24
<
Cheery >
katlogic: you're probably curious about this too. How fast snakelisp is?
11:24
<
Cheery >
or how fast can it become
11:25
<
Cheery >
I'm going to describe the compilation strategy today in my blog.
11:26
<
katlogic >
Cheery: deltablue is about idiomatic code, though
11:26
<
katlogic >
instance creation, inheritance, member access
11:27
<
katlogic >
dunno if you have those, getting rid of those things kinda defeats its purpose :)
11:27
<
Cheery >
I probably won't have inheritance. or not sure.
11:27
<
Cheery >
member access I will have
11:28
<
Cheery >
and probably instance creation too
11:28
<
katlogic >
as for speed, i'm not sure
11:30
<
katlogic >
continuation passing is generally tough sell in compiled code - stack frame trashing ruins register renaming
11:31
<
Cheery >
yes. though the implementation allows calls to C functions, assuming you always keep space in the stack.
11:32
<
Cheery >
it also means you can compile parts of the program into plain C-like functions with explicit stack records.
11:32
<
katlogic >
well, the compiler seems rather naive, i suspect it will be tad slower than custom made asm interpreter
11:32
<
katlogic >
probably a bit faster than c interpreter in microbenchmark
11:34
<
Cheery >
also the JIT isn't closed out.
11:35
<
katlogic >
AOT like this or very naive jit are rather architecturally similiar, yeah
11:35
<
katlogic >
AOT has the advantage that if you play your hand right, compiler can hoist guards for you
11:36
<
katlogic >
which means getting rid of dynamic dispatch most of the time, giving compiler a chance to do code flow analysis
11:38
<
katlogic >
Cheery: There are really good AOT lisp compilers if you want to go high-performance route :)
11:40
<
katlogic >
needless to say; optimizing compilers are humongous
11:40
<
Cheery >
getting this thing to work in the first place using this technique has been sort of enabling.
11:41
<
katlogic >
yeah, direct threaded work for the sake of simply not having interpreter
11:41
<
katlogic >
good for code obfuscation and such
11:41
<
katlogic >
otherwise there is not much benefit, worse it tends to have drawbacks
11:41
<
katlogic >
its like compiling lua code to lua_* api calls
11:42
<
Cheery >
well I can give it an interpreter. actually been planning to because the C compiler is ass-slow :)
11:45
<
Cheery >
say.. after compiling to continuations, I could keep it in the data structures that produces and evaluate it directly
11:45
<
Cheery >
there's everything that's needed for it.
11:46
<
katlogic >
i'm not sure what you really have as continuations
11:46
<
katlogic >
functions? blocks? basic blocks?
11:46
<
Cheery >
the whole program
11:46
<
katlogic >
no, i mean the dividing line for one continuation
11:46
<
katlogic >
its hard to say without seeing source/result side by side :)
11:48
<
Cheery >
I don't inline anything yet.
11:48
<
Cheery >
just got it running. have written and getting used to the language I implement
11:49
<
katlogic >
yeah looks like each opcode equals one C function call
11:49
<
katlogic >
frame->proc(frame, argc, argv);
11:49
<
katlogic >
this is what it ruins it
11:50
<
katlogic >
because the dispatch is completely dynamic, the C compiler can't optimize out anything (boxing of arguments, type guards)
11:51
<
katlogic >
Cheery: you might adopt the V8 approach, though
11:51
<
katlogic >
initially, v8 compiles JS to something very similiar you have there
11:51
<
katlogic >
but it also inserts type-recording instrumentation
11:52
<
katlogic >
and on certain trip count, it compiles hot loops to optimised code based on recorded types
11:52
<
Cheery >
every function here still lacks the gc-overflow checker, and thought about putting breakpoints into every function for debugging
11:52
<
katlogic >
many suspect that approach is unnecesarily complicated though; and result of legacy of V8 being initially very naive JIT like this
11:53
<
katlogic >
gc overflow is checked simply on allocations, uh?
11:54
<
Cheery >
nah. it's not checked at all right now
11:54
<
Cheery >
it crashes if you write a program that uses enough memory.
11:55
<
Cheery >
planning to throw in : if (over_limit()) run_gc(...) in the code generation
11:55
<
katlogic >
oh, you use on-stack vars?
11:55
<
Cheery >
everything sits in the stack
11:56
<
katlogic >
ah, this is what chicken lisp does
11:56
<
Cheery >
though that's not practical if the user allocates something large.
11:57
<
katlogic >
all allocations on stack, and copying gc pulls out used values to new stack frame
11:57
<
katlogic >
to check for overflows, it simply installs trip page when arch supports it
11:57
<
katlogic >
or simply checks for watermark each call
11:58
<
Cheery >
thought about the latter.
11:59
<
katlogic >
well now i look at it what you're doing very resembles chicken lisp :)
11:59
<
katlogic >
though clisp has C function per basic block (meaning it merges list of call statements into one C func)
12:00
<
Cheery >
it might make sense for me to do the same.
12:00
<
Cheery >
anyway I love the speed by which this was possible to create
12:01
<
katlogic >
yeah, lisp is awesome :)
12:01
<
katlogic >
how does it unroll the c stack when gc triggers, setjmp?
12:01
<
Cheery >
going to do the setjmp
12:02
<
katlogic >
you might want to consider if (!continuation1()) ... continuation1: if (!continuation2()) ...
12:02
<
katlogic >
and when gc triggers
12:02
<
katlogic >
simply return :)
12:02
<
katlogic >
(also what chicken lisp does)
12:03
<
Cheery >
hahaa. you mean it implements call as goto; ?
12:03
<
katlogic >
when, possible in same C function, yeah
12:03
<
katlogic >
for example tail recursion loop is usually c function with gotos
12:04
<
Cheery >
and the return causes one super-stack-frame to clean.
12:04
<
Cheery >
that's clever
12:04
<
katlogic >
well, its not single mega-c function
12:05
<
katlogic >
it chops it to several such superframes
12:05
<
katlogic >
anyhow check out its output
12:05
<
katlogic >
that compiler is not particularly efficient either (compared to STALIN or SBCL, or modern JITs), but the tricks there are cute
12:05
<
Cheery >
I guess it may be good idea.
12:06
<
Cheery >
though the trickset is likely very similar to ones already in here.
12:06
<
Cheery >
the compilation strategy is the same
12:07
<
Cheery >
I enjoy the possibility to get the thing running immediately, even if slow. Allows me to figure out what works and what doesn't.
12:08
<
katlogic >
I'm old and bitter and already wrote few half-assed compilers, hence the nagging "you wont beat the big guys".
12:08
<
katlogic >
but hit me up if you'll ever start doing tracing jit, im kinda getting tired of luajit :)
12:11
<
Cheery >
depends on how I'll get the things. Might ask you to look sometime just to verify that the design works.
12:11
<
Cheery >
no the benchmarks but the overall quality of the language
12:12
<
katlogic >
as for design of language semantics, better ask devyn or somesuch :)
12:13
<
katlogic >
Cheery: if i had to nitpick now, s-expressions seemed especially powerful to me together with lists
12:14
<
katlogic >
i'm not sure resetricting oneself only to arrays is a good idea
12:14
<
Cheery >
this is not in yet.
12:15
<
Cheery >
it's sort of another idea to extend the amount of things I'm doing inside the language
12:15
<
katlogic >
good scheme implementations simply optimize list operations to array operations whenever appropiate (ie there are no concatenations of lists)
12:16
<
katlogic >
Cheery: i see, human-readable spin on the whole car-cdr-cons-atom saga.
12:17
<
Cheery >
and here's another thing. slightly lazily copied from wiki page and ported.
12:17
<
Cheery >
I don't know how long these things will last. Wanted to do it this way at first. :)
12:18
<
katlogic >
which reminds me to try quadratic probing in luajit
12:18
<
katlogic >
because its chained hashing is pretty slow as it stands it turns out
12:20
<
Cheery >
I need to get going now. trying to write up a good description of the cps pass, and the compilation to C. also describing the idea of directly interpreting what you get.
12:20
<
Cheery >
well. once I get back.
12:21
<
Cheery >
thanks for giving it a look.
13:32
prophile has quit [Quit: The Game]
13:49
<
gq >
the good news is i reactivated my github acct
13:49
<
gq >
i mean it was never GONE
13:49
<
gq >
i just sort of....forgot about it n.n
13:54
<
purr >
<vil> elliottcable: do I have to scream at yellow paint to use vim? is that why I'm not an expert yet?
13:54
<
purr >
<IamTash> what's klined, hobbits?
13:54
<
purr >
<alexgordon> fuck C++ up the comma operator
13:59
<
Cheery >
I read that the mill architecture is exploiting the C++ comma operator. they're using C++ as an assembly language
14:00
<
Cheery >
they mentioned it in a video too..
14:02
<
Cheery >
every instruction in the architecture can contain 33 distinct operations.
14:02
<
Cheery >
I understood they combine those operations into instructions with overloaded comma operator
14:03
Rusky has joined #elliottcable
15:22
sharkbot has quit [Remote host closed the connection]
15:22
sharkbot has joined #elliottcable
15:52
Rusky has quit [Quit: Leaving.]
16:11
oldskirt has quit [Ping timeout: 245 seconds]
16:21
oldskirt has joined #elliottcable
16:38
prophile has joined #elliottcable
16:48
<
Cheery >
going to a walk. after the walk I'm probably cleaning that up a bit. Might even go far as rewrite my compiler and splatter it there instead. :)
17:01
perrier has joined #elliottcable
17:25
prophile has quit [Quit: The Game]
18:18
Rusky has joined #elliottcable
18:20
Rusky has quit [Client Quit]
18:22
Rusky has joined #elliottcable
18:31
<
Cheery >
updated it
18:36
<
Cheery >
I guess I'll play a game. prep this thing soon and then wire it up for deliver for tomorrow
18:36
<
Cheery >
at once, for a long while, I've got the article ready before the monday :)
18:49
eligrey has joined #elliottcable
19:06
<
alexgordon >
ChanServ: "transpiling" ?
19:07
<
alexgordon >
you mean compiling? :P
19:07
<
joelteon >
cum piling
19:08
<
Cheery >
it's a compiler
19:08
<
alexgordon >
Cheery: well also, since most compilers compile to llvm these days...
19:09
<
alexgordon >
and llvm is a mid-level language like C
19:09
<
joelteon >
alexgordon dropping the knowledge
19:09
<
joelteon >
heya lex
19:09
<
joelteon >
way to go
19:09
<
alexgordon >
joelteon:
*eyebrow*
19:10
* joelteon
transforms into an eyebrow
19:10
* alexgordon
optimizes away joelteon
19:11
<
alexgordon >
NOTHINGS CAN'T SPEAK
19:11
<
joelteon >
speaking of compilers, i'm compiling one
19:11
<
alexgordon >
joelteon: really?
19:12
<
Cheery >
I need to rewrite mine tomorrow
19:12
<
joelteon >
for the third time since yesterday
19:13
<
Cheery >
the cps compiling step from that guy was good
19:13
<
Cheery >
but when I studied it, realised it can be even better and beat shit out of my compiling step
19:22
<
joelteon >
and now openssl's test suite is running
22:37
yorick has joined #elliottcable
22:41
katlogic has quit [Read error: Connection reset by peer]
22:41
katlogic has joined #elliottcable
22:43
eligrey has quit [Read error: Connection reset by peer]