<GitHub98>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vY5gI
<GitHub98>
artiq/new-py2llvm fd46d8b whitequark: Merge branch 'master' into new-py2llvm
_whitelogger____ has joined #m-labs
<whitequark>
why do we need llvmlite-build-as-debug-on-windows.patch
<whitequark>
?
_whitelogger___ has quit [Ping timeout: 240 seconds]
[florian] has joined #m-labs
[florian] has joined #m-labs
<sb0>
on a 7-series FPGA's differential input, is it possible to use the two ISERDESE2 blocks separately? (i.e. deserialize the same data, but with different IDELAY values)
<sb0>
ysionneau, ^
<whitequark>
sb0: so I am rebuilding pipistrello bitstream now
<whitequark>
~hour and counting?!
<sb0>
hmm, never happened here
<sb0>
unless there were gross timing problems
<sb0>
maybe from Robert's latest changes?
<whitequark>
yes
<whitequark>
PAR is going on for 35 minutes...
<whitequark>
rjo: I fixed your linking issue
<GitHub70>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vY5dR
<GitHub70>
artiq/new-py2llvm 3378dd5 whitequark: Fold llvmlite patches into m-labs/llvmlite repository.
_whitelogger____ has joined #m-labs
<GitHub110>
[artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/vYdmt
<GitHub110>
artiq/master b548d50 Sebastien Bourdeauducq: test/coredevice: use ttl_out for PulseRate (loop is less available)
<sb0>
a lot of the uncovered code is device drivers ...
<sb0>
or code that otherwise needs hardware
<whitequark>
sb0: can you please fix travis?
<sb0>
I have never really touched travis and I don't understand what is going on after a cursory look... maybe rjo ?
<sb0>
whitequark, the compiler has to work on windows... /dev/fd/xxx will be problematic
<whitequark>
well
<sb0>
also, python threads are meh...
<whitequark>
they are well-fit for this one task, which is waiting on I/O
<whitequark>
however
<cr1901_modern>
well, msys2 provides /dev/fd, but I suspect it's very limited
<whitequark>
I've spent last 20 minutes trying to make python not set O_CLOEXEC
<whitequark>
so fuck it
<sb0>
PIC is difficult ...
<whitequark>
PIC?
<sb0>
position independent code, as opposed to the current (and working) code that uses a relocatable object and has none of those problems
<cr1901_modern>
Ya know, why do we even HAVE relocation/PIC when virtual memory solves that problem as a side effect?
<whitequark>
wat?
<sb0>
there's no virtual memory on the device and it doesn't solve it anyway
<whitequark>
PIC is not very meaningful without virtual memory
<cr1901_modern>
sb0 answered my q, but...
<whitequark>
I'm using a linker so that I a) have to deal with less relocations b) it will build .eh_frame_hdr
<whitequark>
which nicely integrates with libunwind
<cr1901_modern>
Relocation fixups addresses so programs can be placed anywhere. OSes with virtual memory completely undo that by ensuring that all programs have the same entry point from the program's POV.
<cr1901_modern>
in any case, I'm just thinking out loud
<whitequark>
1) ASLR 2) shared libraries
<rjo>
sb0: i would go for Constant (subclass of Value) and recommending (by convention/coding guidelines) that as something to be passed around. i would not depecate []. fslice(s, slice(a, b, c)) is so much less readable than s[a:b:c] that it outweighs the consistency benefit.
<sb0>
what about C and removing integers?
<rjo>
and i think there has never been a promise that only "digestible" verilog is produced.
<sb0>
well, correct verilog guaranteed would be nice. people run into the occasional annoying buggy corner case from time to time ...
<rjo>
whitequark: could you "mv lit-test test/lit"?
<whitequark>
test/lit/test/...
<sb0>
many of those corner cases require complicated code to fix, unfortunately
<whitequark>
plus it's not in the usual format. But sure, if you really think it's necessary
<rjo>
but migen does not want to catch circular references for example.
<sb0>
circular references?
<rjo>
sb0: C() and removing integers is a bit harsh imho. but yeah well.
<rjo>
a.eq(b), b.eq(~a). or even a.eq(~a).
<rjo>
in comb
<sb0>
ah, unstable comb loops
<sb0>
they're valid verilog
<rjo>
but not digestible.
<rjo>
which is the relevant parameter imho.
<rjo>
generating technically valid verilog and not being able to do anything with it is close to useless imho.
<rjo>
so i would just forget about working around all corner cases that make ise/vivado/quartus stumble.
<sb0>
ok, but those originate from a bug in the design
<sb0>
whereas C(16)[1:2] is legit, but verilog compilers will choke on the generated code I think
<cr1901_modern>
Has the Cat() bug popped up in Artiq yet?
<sb0>
no because all those corner cases can actually be easily avoided manually
<rjo>
slicing lhs Cat?
<cr1901_modern>
Yes, that's a better name lol
<cr1901_modern>
It's valid in Migen (and kinda logical, IMO), but Verilog chokes on it
<rjo>
in general a Signal().proxy() method would be nice for these things. Also Array() could use it.
<cr1901_modern>
Signal().proxy()?
<rjo>
sb0, whitequark: we need a bit more people to understand the CI stuff than just Yann (vacation) and me. And you guys broke it. IMHO you are very capable of fixing it.
<whitequark>
I have absolutely no idea what happened to it, that's why I'm asking
<rjo>
cr1901_modern: gives you a proxy signal that you can lhs-slice.
<rjo>
whitequark: your llvm/binutils changes happened, no?
<cr1901_modern>
Well, THAT would've been nice to know last month lol
<whitequark>
rjo: I haven't touched migen.
<whitequark>
in fact, I haven't touched any Python there when it broke
<whitequark>
which is why I'm so confused about it.
<rjo>
i bet you can reproduce it locally. the stuff should be runnable locally and does not need root.
<whitequark>
hrm
<rjo>
i don't have magic dust and don't see the bug after having a had a cursory look either. so i would do the same.
<whitequark>
i suppose
<GitHub47>
[artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vYbhg
<whitequark>
rjo: had them in my ~/.XCompose for a long time
<whitequark>
along with <Compose> <t> <f> (╯°□°）╯︵ ┻━┻
<rjo>
you must feel very disappointed that -- while you can map all kinds of shapes -- there is are no unicode modifiers for color.
<whitequark>
there actually are.
<whitequark>
well, skin color modifiers for emoji, but still, there are.
<rjo>
good lord. how racist.
<whitequark>
?
<rjo>
but color in unicode would have really smart. then all those escape sequences can finally go (in 500 years)
<rjo>
there is no red, yellow etc.
<rjo>
it is just a one-dimensional scale from a light "kaukasian" (as the americans call it) to a dark brownish tone.
<whitequark>
ah. I suppose
<rjo>
"the Fitzpatrick scale"
<whitequark>
speaking of color, you could treat 256-color escape sequences as such
<whitequark>
unambiguous (there's only one way to encode those as far as I know), and valid Unicode too.
<rjo>
ah no. it gets better: "When a human emoji is not immediately followed by a emoji modifier character, it should use a generic, non-realistic skin tone, such as:" and here it comes: blue
<whitequark>
imo the only good thing about emoji is that you can finally block them all in a uniform way
<rjo>
but iirc the palette is not defined.
<cr1901_modern>
Can't wait for *nix kernel terminal drivers to support Unicode emoji
<whitequark>
was harder when every website used images or such.
<whitequark>
ah right. the palette isn't.
<rjo>
yeah. and logging.DEBUG == "
<rjo>
that broke.
<rjo>
U+1F913 NERD FACE
<whitequark>
...
<cr1901_modern>
That would be a very valid use of kernel dev's time.
<rjo>
you have to factor in that U+1F913 uses less screen space than "[DEBUG]" and is quicker to understand.
<whitequark>
is there a python benchmark library that *works*?
<cr1901_modern>
What's wrong with the built-in profiler?
<whitequark>
which one?
<cr1901_modern>
The only one I've used. I know that's not helpful, so I'll see if I can't figure out which one I used. XD
<cr1901_modern>
I think I just used the raw Python profiler
<cr1901_modern>
"The profiler modules are designed to provide an execution profile for a given program, not for benchmarking purposes"... oh.
<cr1901_modern>
They subsequently mention timeit, which I assume you used and it didn't suit your needs
<GitHub95>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYNCx
<GitHub95>
artiq/new-py2llvm 3b5d3e2 whitequark: Add a performance measurement testbench.
<rjo>
timeit and cProfile are nice. ipython makes them really convenient.
<whitequark>
so, for lit-test/test/integration/arithmetics.py, which is quite heavy on branchs
<whitequark>
11 ARTIQ typechecking and transforms runs: 5.34s, 485.54ms/run
<whitequark>
21 LLVM optimization and linking runs: 5.25s, 249.90ms/run
<GitHub176>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYNBu
<GitHub176>
artiq/new-py2llvm 6d8d0ff whitequark: Update performance testbench to include time spent in ARTIQ.
* rjo
twitches
<whitequark>
a release (even lto) build of LLVM without assertions will be much faster, but I won't be the the one who builds it today
<whitequark>
and assuming the types of kernel parameters don't change, we can skip ARTIQ typechecking/transforms most of the time when modifying those
<whitequark>
but this should be the ballpark
<rjo>
>10ms per line of assert. gulp.
<whitequark>
oh dear god
<whitequark>
I have this code that assigns names to IR instructions that's quadratic
<whitequark>
79 ARTIQ typechecking and transforms runs: 5.04s, 63.79ms/run
<GitHub157>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYNuO
<GitHub157>
artiq/new-py2llvm d7f9af4 whitequark: Fix accidentally quadratic code in compiler.ir.Function._add_name.
<cr1901_modern>
whitequark: Is the quadratic part that the while name in... always run, while the "typical" case is to just add a new name (I'm just seeing if I understand)?
<whitequark>
no, that if you repeatedly add the same name, it takes one more step to generate an unique one every time
<whitequark>
or maybe yes, depending on what you mean exactly
<cr1901_modern>
Nah, I misunderstood it the algorithm. :P If I don't understand something you/others say in this room, I try to see if I can figure it out for myself. Then ask if the room's quiet or leave it for another time.
<whitequark>
of course, the *real* issue is that calling into LLVM C API is even slower
<whitequark>
none of the above would be a problem if python had a real runtime and not some rudiment from 1995
<whitequark>
like, for example, JVM.
<whitequark>
anyway, most of the time ARTIQ wastes is spent in the parser, which is good, because it's trivially cacheable. just have a dict of sha1(code)->AST
<GitHub32>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYNdH
<GitHub32>
artiq/new-py2llvm b0185f3 whitequark: Add profiling to the performance testbench.
<cr1901_modern>
How long was the full test (at least .701, but am curious about ratios)?
<whitequark>
5s
<whitequark>
2/5 is spent inside LLVM
<whitequark>
the rest, mostly concatenating strings
<cr1901_modern>
I agree that Python isn't exceptionally fast, but what's wrong with it's C FFI such that'll push that ratio up?
<whitequark>
I dunno, actually
<whitequark>
but I doubt numba people would just go and rewrite it from scratch if it was easily fixable
<cr1901_modern>
FOSS is about choice in Python FFI bindings
<whitequark>
ohhhhh i see
<whitequark>
llvmpy has some kind of extremely generic wrapper around C++ memory management, that allows it to wrap much of LLVM's innards
<whitequark>
if it used the C API, this would probably not have been a problem on python.
<rjo>
whitequark: ack to speed. llvmlite is merely a templating engine.
<whitequark>
well, the IR parts of llvmlite.
<whitequark>
thankfully it does not require me to shell out to optimize or codegen.
<whitequark>
I'd say "redo it via the C API" but the C API has usability issues. it tends to segfault if you use it wrong, or in best case, give you an unhelpful backtrace that doesn't mention Python function names
<whitequark>
so there's some truth to emitting LLVM IR assembly and re-parsing. but, slow.
<cr1901_modern>
And according to the llvmlite page, some functionality just isn't possible with the C API. Tbh the profiling numbers whitequark pasted earlier don't SEEM that bad to me.
<cr1901_modern>
But I'm not working on Artiq, so I'm prob missing someting
<whitequark>
imagine a 500-line file taking up to 10 seconds to compile
<whitequark>
("amount of lines" is an extremely bad measure of complexity, so i'm assuming it will be some fairly contrived code.)
<cr1901_modern>
Well, most ppl would get impatient/think there's something wrong
<whitequark>
sb0: so I am looking at the compilation model that old py2llvm had
<whitequark>
do I understand correctly that such things as drivers were pulled in by the compiler, i.e. if you do self.dds.init, it looks up the method, sees that it has @kernel, and proceeds to also compile it?
ylamarre1 has quit [Quit: ylamarre1]
<rjo>
yes and inline it.
<whitequark>
*always* inline? that seems odd
<whitequark>
anyway, the nature of my question was... the current compilation model is designed much like python's
<whitequark>
you get a module, which corresponds to a single LLVM translation unit, and within a module all types should be known
<whitequark>
I'm currently pondering whether it maps well to what ARTIQ does
nicksydney_ has joined #m-labs
nicksydney has quit [Ping timeout: 244 seconds]
<rjo>
currently it is always inlined. but it should be left to llvm to decide that in most cases.