we kind of suck at our job

[Raoul Duke]

i like how we have to outsource code to the gpu or the neural engine
and it is basically hard coded strings from the main app code and you
can't really do anything with it and you can't debug it at all let
alone interactively and it is just a freaking pile of crap from any
kind of self-respecting UX perspective.

ok yeah there's various shadertool type things that are mini
playgrounds so that's a step in the right direction. i haven't seen
that fully integrated with a real e2e ide feeling yet????????

[David Barbour]

Haskell's Accelerate library has a reference implementation on the CPU but is meant for offloading the same operations to GPGPU. I think this is a better direction, in general - use GPGPU as a software accelerator, but always have a sensible interpretation that doesn't require the GPGPU to process.

--
You received this message because you are subscribed to the Google Groups "PiLuD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pilud+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pilud/CAJ7XQb4hOFPVnUEyZ_n-7yGBuroo%3DfXqPRhY-pTZoJ4hCu6gOQ%40mail.gmail.com.

[Raoul Duke]

that's what lots of ML systems already do in some hand waving sense but it is really quite undebuggable crap ux when anything hoes even slightly wrong. 

To view this discussion on the web visit https://groups.google.com/d/msgid/pilud/CAAOQMSvbv-wYgewHUtxMUVRtK3JPdohh%2BpdJC%3DeEAmN8%2B%2B3C_g%40mail.gmail.com.

[David Barbour]

Machine Learning is not very debuggable, just in general. It's heuristic weights all the way down. All you can do is treat it as a black box and test it to your satisfaction.

But there are plenty of more debuggable uses of a GPGPU - physics sims, rendering, visual or audio processing, etc. 

To view this discussion on the web visit https://groups.google.com/d/msgid/pilud/CAJ7XQb6iQWAaiLuSE186aR0%2Bax%3DN2-SPxB-PQ9MTxBATjM-2HA%40mail.gmail.com.

[Raoul Duke]

heh We might keep talking past each other... I'm not talking about
debugging the network behaviour why-did-it-run-over-that-pedestrian, I
mean just getting the source model (a) into a format that will run on
the device(s) and (b) all the nuances around that, all the
optimizations, (c) debugging everything / anything from "it doesn't
effing work" to "why is it slow" etc.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pilud/CAAOQMSt8TtXACBXFbG0xjwmhoX9V_btNZvbBH2vfWxGCXuWNkw%40mail.gmail.com.

[David Barbour]

Ah. I suppose that might be a problem if you were building a hard-coded string. But with techniques like Accelerate, you'll usually programmatically build a type-safe AST for the program that will later run on the GPGPU, and conversion to a string is left to a library. There is almost no risk that the format will be wrong. There is a minor risk that you'll want more resources than the device can provide you. The biggest risk is still that you didn't properly encode your model into linear algebra, but that's always a risk unless you have excellent libraries. 

[Raoul Duke]

$0.02 i will never believe it will be utterly without failure or bugs, that there is never a need to debug and thus to want good top to bottom back to front end to end tools. for anything about programming. 

--
You received this message because you are subscribed to the Google Groups "PiLuD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pilud+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pilud/CAAOQMSuTMGYCx-AXfKENF_j31v9%2BdRnQwRVoYSPQ-CR%2BesfPDA%40mail.gmail.com.

[David Barbour]

We'll never be able to debug a GPGPU or FPGA the same way we might debug a local app, e.g. with gdb and step-thru. But if you can debug the logic via local simulation independently from debugging the remote accelerator, that's a really good idea. The problem is *probably* not in the compiler, after all.

We cannot eliminate all risk of bugs, but if we can control the risk via isolation of different issues, that's already a big improvement.

To view this discussion on the web visit https://groups.google.com/d/msgid/pilud/CAJ7XQb7AWM1QSa5Dy_10cCy2gOQDrXMc3u8oaJWHdq1t_YGvwQ%40mail.gmail.com.

[Raoul Duke]

yes id definitely be happy if eg the command line network compiler tool actually could write errors to stdout, not just syslog. i mean the bar is very very low. :-(

To view this discussion on the web visit https://groups.google.com/d/msgid/pilud/CAAOQMSuZ5%2BMw%3DWqzy4TFVSBZoxjNbJpLSX7ymTA3jBbbEES23w%40mail.gmail.com.