yorick has quit [Remote host closed the connection]
sephr has joined #elliottcable
<elliottcable>
hi
<purr>
elliottcable: hi!
alexgordon has quit [Quit: Computer has gone to sleep.]
brr has quit [Ping timeout: 260 seconds]
brr has joined #elliottcable
<micahjohnston>
devyn: yeah it's cool
<micahjohnston>
I'm currently, meta-figuratively, “literally in hell.”
<devyn>
I'm writing an OpenCL application. I feel yah :/
<devyn>
micahjohnston: dude GPUs are fast o.o
<micahjohnston>
devyn: ya
<micahjohnston>
my friend is building a computer
<micahjohnston>
and waiting for the next month release of gpus :p
<devyn>
who, Caius? I told him he should just get an HD 7970…
<devyn>
NVidia 7xx isn't a huge improvement in anything other than GPGPU and will cost so much more
<devyn>
(vs. 6xx)
<devyn>
whereas AMD's cards are much cheaper and already good at GPGPU and gaming
<devyn>
lol!
<purr>
lol
<devyn>
I think I just wrote a program that corrupts my VRAM on OS X
<devyn>
lol.
<purr>
lol
irclogger_com has quit [Read error: Operation timed out]
irclogger_com has joined #elliottcable
<sanitypassing>
why would you do that?
<sanitypassing>
other than for shits and giggles
<devyn>
t'was an accident
<devyn>
I'm writing bbbattle for GPU
<sanitypassing>
oh I see.
<sanitypassing>
... I need to get started on a project
<sanitypassing>
I feel so lazy sitting around doing (almost) nothing.
<devyn>
sanitypassing: dude I ran 1000 generations of a 1024x1024 sim on my *MacBook*'s GPU (3 years old, integrated, opposite of high end)
<devyn>
in like 17 seconds
<sanitypassing>
via bbbattle?
<devyn>
bbbattle OpenCL yes
<devyn>
:D
<sanitypassing>
I see.
<devyn>
on my high end 8-core CPU that takes a minute and a bit?
<devyn>
:p
<sanitypassing>
heh.
<sanitypassing>
OpenCL is nice.
<sanitypassing>
Never used it personally, but I like the idea of it.
<devyn>
no it's not, I want to kill it with fire, but what you can do with it is nice
<sanitypassing>
graphics cards can just handle so many more operations of a certain type than a traditional processor
<devyn>
anyway I can't wait to get this running on Windows with my Radeon HD 7950
<devyn>
which is a super high end card :p
<sanitypassing>
heh.
<sanitypassing>
hmm, which would you say is better for overall performance: C or C++?
<sanitypassing>
provided stuff like SSEx and other such optimizations are used.
sephr has quit [Quit: Leaving]
<devyn>
I don't think they're really all that different anymore. But both languages will make you want to kill yourself if it's anything big.
<sanitypassing>
well yeah
<sanitypassing>
I think any low-level language is like that.
<devyn>
sanitypassing: lol so I'm using Haskell to convert memory dumps from C into PNG files because I'm not quite ready to handle that in C yet :p
<purr>
lol
<devyn>
the C part of the program is a clusterfuck, anyway, actually
<sanitypassing>
well then why do you even have a C part of the program?
<devyn>
it's a frankenstein of 3 different OpenCL examples, modified into something to fit the bbbattle_step kernel
<sanitypassing>
... or do you need it for OpenC:?
<sanitypassing>
OpenCL
<sanitypassing>
derp
<devyn>
because you need C to call OpenCL unless you're going to use some shitty bindings
<devyn>
:p
<sanitypassing>
hmm.
<sanitypassing>
Write a new binding!
<sanitypassing>
or improve an existing one.
<devyn>
C is portable to Windows. That's all that matters.
<sanitypassing>
it would take time, obviously, but then other people would benefit from it
<sanitypassing>
which is always nice.
<devyn>
I'm good with doing it in C :p
<devyn>
it's only a 166-line C program, which is pretty good for C
<sanitypassing>
hmm.
<devyn>
but it's also shitty and doesn't really have error handling, just tons of assert() :p
<sanitypassing>
... you should write proper error handling.
<sanitypassing>
the you three months from now will be thankful.
<devyn>
lol, well, assert() gives the line number which is good enough for C right now, and proper error handling in C is not fun at all
<purr>
lol
<devyn>
so I'm good with this for now
<sanitypassing>
"for now".
<sanitypassing>
I'll quote you on this someday.
<devyn>
this program is not likely to exceed a thousand lines, which is a perfectly debuggable size
<devyn>
sanitypassing: 1024x1024, starts (0th generation) http://cl.ly/P8pM, then in 17 seconds and 1000 generations later, http://cl.ly/P9Cr
<sanitypassing>
that's kinda awesome.
<devyn>
fuck yeah GPU
<devyn>
wait this isn't bbbattle
<devyn>
hold on
<sanitypassing>
lol
<purr>
lol
<devyn>
sanitypassing: had to change the topic so mordof'll see it
<devyn>
haha
<sanitypassing>
heh.
brr has quit [Ping timeout: 240 seconds]
brr has joined #elliottcable
<devyn>
sanitypassing: still there?
<sanitypassing>
not for much longer
<devyn>
so
<sanitypassing>
falling asleep. D:
<devyn>
sanitypassing: 1024x1024, 20000 generations on an AMD Radeon HD 7950
<devyn>
(yes I got it working)
<devyn>
guess how long
<sanitypassing>
time?
<devyn>
guess
<sanitypassing>
<5 seconds?
<devyn>
2.87 seconds
<sanitypassing>
daaamn
<sanitypassing>
original test on your mac was how many generations?
<devyn>
1000
<sanitypassing>
so this is x20 generations?
<devyn>
yes, and 1000 gens on the MacBook was 17 seconds :p
<devyn>
and that 17 seconds for 1000 gens is actually better than the Haskell version running on an 8-core CPU
<devyn>
by a factor of 5 or 6
<devyn>
so this is just crazy
<devyn>
:p
<sanitypassing>
how fast was 1000 generations on the Radeon?
<devyn>
0.670, and a lot of that is setup overhead :p
<sanitypassing>
hmm.
<sanitypassing>
based on 20,000 generations, if I math'd right (which, admittedly, it's 2:41 am, so I may not have), 1,000 generation should take ~0.143 seconds, assuming the speed of calculation is the same.
<sanitypassing>
so you've got ~0.500 in overhead.
<devyn>
you're neglecting the fairly significant setup time that applies to both of 'em
<sanitypassing>
I know.
<sanitypassing>
just thinking
<devyn>
the kernel has to be compiled before it can be executed on the GPU. there's literally a big blob of OpenCL source code in the binary :p
<sanitypassing>
that's a nice start up time though
<sanitypassing>
does the kernel need to be compiled at each start up?
<sanitypassing>
or can it be cached in some way?
<devyn>
I could cache it if I want; the OpenCL API allows you to dump the compiled form of the binary
<sanitypassing>
that could probably shave a few ms off the start time
<devyn>
which is of course specific to that particular GPU architecture, so something compiled for a 7950 or 7970 won't run on anything else :p I'd have to tag it with the params used to compile it
<devyn>
and the device
<sanitypassing>
though it would take more time to get a new copy of the opencl code running, since you would have to recompile
<sanitypassing>
though you could check to see if a dump exists, if so, confirm stability and use. If not, recompile and save dump for later use.
<sanitypassing>
(if you can confirm stability)
<devyn>
now I'm not sure what you mean :p
<sanitypassing>
okay
<sanitypassing>
lemme try again
<devyn>
I'd just leave the dumps and delete 'em when I want it recompiled
<sanitypassing>
well yeah
<devyn>
well I can get the device name, so I could output bbbattle-Tahiti.bin for example for a 7950 or 7970
<sanitypassing>
but what I was saying is you can write in code to see if one of those dumps exists. If so, use it and don't recompile. If it does not exist, compile and dump for later use.
<devyn>
…yes? that's exactly how anyone would do it…?
<sanitypassing>
... I can't brain.
<devyn>
lol
<purr>
lol
<sanitypassing>
I'm just mixing up shit in my head at this point, I think
<devyn>
but shit, man
<sanitypassing>
anyway
<devyn>
bbbattle 1024x1024 20000 gens
<sanitypassing>
that's goddamn fast though
<devyn>
in 2.80
<devyn>
I've got mordof's implementation beat like, how many times by now?
<devyn>
probably hundreds to thousands
<devyn>
:p
<sanitypassing>
iheh.
<devyn>
of course once I actually have to pull the data out from the GPU to render it
<sanitypassing>
s/i//
<devyn>
it'll slow down
<devyn>
right now I'm only pulling the final generation
<sanitypassing>
why doesn't the GPU render it?
<devyn>
and just doing a memory dump
<devyn>
because that would require me learning OpenGL too
<sanitypassing>
or is it not that kind of rendering?
<sanitypassing>
OpenGL and OpenCL share a common API
<sanitypassing>
and you don't necessarily have to learn OpenGL. Just use something like SDL
<devyn>
no, they don't; you can share CL objects with GL
<sanitypassing>
which is significantly easier.
<devyn>
or DX for that matter
<sanitypassing>
I mean like API names.
<sanitypassing>
I think
<sanitypassing>
been a long time since I've looked at either
<sanitypassing>
~2 years?
<sanitypassing>
I dunno.
<devyn>
and I have used SDL but that's CPU-bound
<sanitypassing>
I thought they changed that.
<devyn>
well you can get the OpenGL context from it :p
<sanitypassing>
but that isn't THAT hard to do anyway
<devyn>
of course not, but it still means I have to learn OpenGL
<sanitypassing>
MMm.
<devyn>
and anyway
<devyn>
no point really really really
<devyn>
I mean
<devyn>
what I really would end up doing is exporting this to bbbout or some better format I dream up
<sanitypassing>
is the code for this on github?
<devyn>
and then streaming that to browsers
<devyn>
and they render that data
<sanitypassing>
oh this will be browser based?
<devyn>
probably
<devyn>
maybe not
<sanitypassing>
so send raw data to the browser and let <canvas> do hardware acceleration for you.
<sanitypassing>
stream it via websockets or long polling or something
<devyn>
<canvas> isn't really all that fast, even hardware accelerated
<sanitypassing>
faster than CPU rendering.
<sanitypassing>
... possibly.
<sanitypassing>
would have to benchmark
<sanitypassing>
if I knew how to use <canvas>
<devyn>
not for putting single pixels
<devyn>
on a surface
<sanitypassing>
but there is also WebGL
<devyn>
for that you want WebGL :p
<sanitypassing>
Which IS more complex
<sanitypassing>
than canvas
<sanitypassing>
but easier I've heard than OpenGL
<devyn>
in Canvas you'd have to create tons and tons of rects which have more overhead than just placing a pixel
<sanitypassing>
since I think it's just a frag shader and vertex shader
<devyn>
yes, it's OpenGL ES API ported to JS
<sanitypassing>
but OpenGL has those too I suppose
<elliottcable>
Nobody's ever here when *I'm* here.
<elliottcable>
This never used to be a problem. )'=
<alexgordon>
hi elliottcable
<alexgordon>
lol
<purr>
lol
<elliottcable>
o7 alexgordon
<alexgordon>
that's all I ever say
<elliottcable>
what's up?
<elliottcable>
I don't know anything about you right now.
<elliottcable>
Still toiling away on your text-editor?
<elliottcable>
You said you were doing something with Rails, right?
<elliottcable>
Anything *interesting*?
<alexgordon>
elliottcable: bitcoin exchange
<alexgordon>
doing some work for one
<alexgordon>
I guess that's interesting!
<elliottcable>
seriously!?
<elliottcable>
waitwat.
<elliottcable>
you're into bitcoin? since when?
<alexgordon>
elliottcable: since a few months ago
<alexgordon>
lol
<purr>
lol
<alexgordon>
elliottcable: since you told me about that ASIC miner
<alexgordon>
realized it was Serious Business
<elliottcable>
alexgordon ⑊ which ASIC miner?
<alexgordon>
elliottcable: I think it was the BFL one, but just the concept of ASIC miners in general...
<alexgordon>
strike me with awe
<alexgordon>
if someone is willing to spend that kind of money designing and fabbing a computer of that scale, it's no longer just some geeks pissing around anymore
<alexgordon>
elliottcable: I'd been thinking of building a bitcoin exchange, but I can't be bothered to do all the bureaucratic stuff of forming a company and a bank account in another country, so I did the next best thing and offered to improve an existing one
<elliottcable>
hah!
<elliottcable>
alexgordon ⑊ excellent.
<elliottcable>
hold on, working on some IRC hook shit