lekernel changed the topic of #m-labs to: Mixxeo, Migen, MiSoC & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
nicksydney has joined #m-labs
FabM has joined #m-labs
mumptai has joined #m-labs
stekern has quit [Ping timeout: 245 seconds]
stekern has joined #m-labs
mumptai has quit [Quit: Verlassend]
stekern has quit [Ping timeout: 260 seconds]
stekern has joined #m-labs
sb0 has joined #m-labs
xiangfu has joined #m-labs
sh4rm4 is now known as sh4rm4_
sh4rm4_ has quit [Remote host closed the connection]
sh4rm4_ has joined #m-labs
sh4rm4_ is now known as sh4rm4
rjo_ has quit [Ping timeout: 245 seconds]
_florent_ has joined #m-labs
zumbi_ is now known as zumbi
gric has joined #m-labs
Alain_ has joined #m-labs
xiangfu has quit [Remote host closed the connection]
xiangfu has joined #m-labs
xiangfu has quit [Quit: leaving]
_florent_ has quit [Ping timeout: 240 seconds]
sh[4]rm4 has joined #m-labs
sh4rm4 has quit [Ping timeout: 252 seconds]
rjo_ has joined #m-labs
rjo_ has quit [Ping timeout: 240 seconds]
<rjo> sb0: i see you are already going down the rabit hole of generating code with llvm. nice!
<rjo> sb0: i assume the decision for or1k was due to its better llvm status?
<sb0> yes
<sb0> the llvm backend is up-to-date, less buggy, has more features (like the integrated assembler), and according to the coremark test doesn't generate worse code than gcc
<sb0> (I've seen llvm-lm32 generating pretty bad code...)
<rjo> sounds good. i'll try to get ventilator running on or1k.
<rjo> ... too big.
Alain_ has quit [Remote host closed the connection]
<rjo> ah no it barely fits but looks like it will fail to route.
<sb0> rjo, have you tried numba/pycc extensively?
<sb0> I've managed to run or1k on the ppro, but without your timing core
sh[4]rm4 has quit [Remote host closed the connection]
sh[4]rm4 has joined #m-labs
sh[4]rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
<rjo> sb0: i use numba for numerical things. yes. but that is with x86 as target.
<rjo> sb0: but i have only glanced at how it works in detail.
<rjo> sb0: did or1k achieve similar frequency as lm32?
<sb0> I'm not too impressed with pycc
Alain has joined #m-labs
<sb0> yes, 83 1/3 MHz on both mixxeo (lx45) and ppro
<rjo> sb0: why not?
<sb0> it generates weird code even on simple input like "for i in range(50): a += 2*i"
<sb0> creating an array in the compiled function does not work
<sb0> lists are unsupported
<rjo> sb0: iirc they say that it will end up being good assembly after llvm is done with it.
<rjo> sb0: yes. it is somewhat numerics-centric.
<sb0> no, I looked at the assembly (targeting x86_64) and was about as weird/large as the LLVM IR
<rjo> sb0: you would not have python lists.
<rjo> sb0: ok. hmm.
<sb0> maybe I missed some optimization passes? I just ran export() in pycc
<rjo> sb0: passing it the signature?
<sb0> yes
<rjo> hmm. their examples even have code like that: http://continuum.io/blog/numba_performance
<sb0> it works fine for simple functions, but as soon as you start doing certain loops, the code becomes weird
<sb0> I broke my numba install while messing with llvm-or1k so I don't have immediate examples... but I could find them again
sh[4]rm4 has joined #m-labs
sh4rm4 has quit [Ping timeout: 252 seconds]
<sb0> I'm also not sure how much of numba we actually want... for simple cases, python ast to llvm isn't hard
<rjo> sb0: yes. i was also thinking that for actual computations one might get away with "inline C"-to-IR instead of AST-to-IR.
<rjo> sb0: it would look a bit weird though
sh[4]rm4 is now known as sh4rm4
<sb0> AST-to-IR is definitely feasible, easier to use, and cleaner
<rjo> sb0: yeah. i have no real experience with that. maybe one could strip/recycle parts from numba for that.
<rjo> which llvm commands gets me assembly from IR?
<rjo> sb0: llvm installation is a big mess...
<sb0> in pyllvm?
<sb0> *llvmpy
<rjo> sb0: pycc gives me llvm-ir, but i would like to look at assembly.
<sb0> doesn't it produce a .so file?
<sb0> pycc somefile.py produces somefile.so here
<sb0> and then objdump -d somefile.so
sh4rm4 has quit [Remote host closed the connection]
<sb0> and yeah, the llvm installation is a big mess - hopefully it will get better after or1k is upstream, llvmpy supports llvm 3.5, and distributions package those (arch linux tends to be better in this respect)
<rjo> http://paste.debian.net/103070/ doesn't look too bad, does it?
<rjo> yes. i overlooked the .so.
<rjo> http://paste.debian.net/103074/ looks more digestable to me.
<sb0> with the same input?
<rjo> yes
<sb0> huh
<sb0> what's the ir like?
<rjo> this is numba 0.13.0, llvmpy 0.12.4-1-git something, and afaict even llvm 3.3
<rjo> the xrange vs range apparently does not matter.
<sb0> hmm, yes... I'm using llvm 3.4, and numba and llvmpy from git
<sb0> it won't accept xrange here: "numba.typeinfer.TypingError: Untyped global name 'xrange'"
<sb0> python 3?
<rjo> updating my numba toolchain is on my list. i'll see whether that makes a difference.
<rjo> no python 2.7
<sb0> ah, maybe that's the reason
<sb0> I've only tried numba with python 3.3+
<rjo> maybe. i don't even know when python3-numba landed.
<sb0> they might have some py3k bugs around
<sb0> rjo, in your list sum example, changing the signature to "i4(i4[:])" creates a mess here
<sb0> with f8, it works like on your computer
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
Alain has quit [Read error: Connection reset by peer]
Alain has joined #m-labs
sb0 has quit [Quit: Leaving]
<rjo> sb0: i4 and f8 both look reasonable here. and nominally xrange and range should work both. http://numba.pydata.org/numba-doc/dev/spec.html sounds like py3k issues to me...