| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13
Comments:
<0> I must arrange to see the research group again, actually. they sent me off with a load of stuff to read, and I'm about half way through
<1> You can just query the data
<2> so, MrAshes, can you explain how you did it?
<1> Which part?
<0> of course, it was all written for post-docs who just wanted to get into the field, so it's a bit of hard work
<3> Asriel ill be waiting patiently until you come to london which you hate so much
<0> :) I'll be up for the imperial open day before the year's out
<0> or earlier next year, depending on when you hold it
<3> great
<2> about having thread heavy working on you cores without getting slow cause of the synnchronization?
<4> has anyone ever coded a game for multiplaying using either UDP or TCP/IP ?
<0> and I'm up there every other month anyway, we should get together for a beer :)
<3> agreed
<0> or possibly, multiple beers. then spirits. then hookers. actually, forget the beers
<1> Klaim: synchronization has never been slow
<2> is it just to limit synchronization mecanism to it's most efficient way, or is it a special program architecture?
<1> It's the architecture that changes
<3> Asriel :) Ill bring my gf with me, shell love the hookers
<0> ideally, your threads should "link together" as little as possible
<1> Instead of rendering, the data to be rendered is queued in some kind of special queues (with priorities and a bunch of other parameters)
<1> Then another thread simply sends data from the queue to the graphics card
<1> (async)
<1> So basically the card suffers
<1> And the CPUs too
<1> And it's fast
<0> whenever two threads are accessing the same data, or talking to each other, you've got pain to deal with
<3> all this stuff should be automated
<0> and multithread induced bugs are almong the worst you'll ever have to fix in your life, ever
<2> like, sending just matrices and data loading queries?
<2> or just animation launch message etc?
<1> I don't set matrices
<3> Asriel, NASA knows about that too :)
<1> I don't use the fixed pipeline
<0> because the damn code will run for 99999 out of 100000 operating hours, then randomly fall over due to the probability of the race condition actually failing being something about 10^-100
<3> indeed
<1> Asriel: gotta love those
<1> Asriel: especially when they trash your stack at the same time and turn your app into random stuff :D
<3> MrAshe, and you are still not 100% sure your code is absolutely correct
<2> i see, so it's more like an optimised network messaging system between cores, is'nt it?
<0> oh yes. pain, pain, pain
<0> and you're never ever sure you've done it perfectly
<1> Klaim: what??
<2> uh
<0> hence my return to academia to try and help fix this crap
<3> Asriel, unless your formally prove it correct - which is a pain too
<2> you define some messages that are simples and use it to communicate between threads?
<3> so please make a good phd thesis about this, so you can fix this nightmare
<0> heh. I wouldn't even know where to start on formally proving a 100,000 line C++ codebase
<1> Klaim: the threads don't communicate, they process stuff
<1> Asriel: this thing is about to reach 500k :D
<3> Asriel, the highlevel shouldnt be C++ per se
<0> just specifing what the system should do in a precise enough language would occupy someone for years
<5> lots of people working on PhDs in here
<5> weird.
<1> Asriel, IRR
<0> oh no, of course not. but still
<3> the highlevel could be compiled to C++
<0> formally proving small algorithms is still a pain in the ***
<2> Ok, then what i don't understand is how do they synchronize when, for example, the player change position (in game) and that have to be done graphically to ?
<3> I agree
<3> Asriel, but NASA does formal proving on its software
<0> hell, even proving bubble sort works requires both forumlating a suitable invariant then applying induction
<2> there should be copmmunication between threads , no?
<1> Klaim: mutex on the player position
<0> 10+ minutes for something that you can code in 30 seconds
<1> + the player's rendering is always done by the same thread anyway
<3> Asriel I agree, Ive been through that pain in first year :)
<1> It's just to avoid issues between the input/network/physics threads (which change the position) and the renderer
<2> yes it was a bad example but i think you understood what i was asking
<0> didn't do a whole lot of formal proofs on the CS side (only a minor). But 90% of the math lectures are proof
<1> No I don't, the threads don't communicate
<0> which is fine by me :)
<1> Except when they have to start/stop
<1> Otherwise they're mostly independent
<2> ok but they access the same data to be synchrone
<0> aside from the fact that most of this year is applied math, and the exams will be "application" based rather than too proof heavy. Yet the lectures are still 90% proving it works, 10% applying it
<0> ah well, the joys of math :)
<3> the only way to be sure about a multi threaded program working correctly is through proving, there is just too much mental overhead
<1> Klaim: what?
<1> Klaim: they process different data, otherwise it's useless
<1> (and they're not synchronous, that's the point)
<0> one could never be sure any given program on a given OS worked anyway
<0> you could prove your code was flawless
<1> Hello world usually works
<0> and then have it fall into an OS level API bug
<1> But then maybe the OS lib behind it is flawed
<3> I agree :)
<3> so prove the OS
<3> prove the soft
<0> prove the hardware
<3> prove everything :)
<1> Windows is easy to prove
<1> It's flawed
<3> hehe
<1> (just like all the other ones)
<3> Linux however is "perfect"
<0> hell, we're getting into weird quantum effects at the processor level already
<1> And Intel gives a list of bugs weeks before releasing CPUs
<2> the data that is mutex, it is shared between 2 threads a least , because if not it don't have to be mutex, no?
<6> Use formal methods to prove :D
<1> So you know they're flawed as well
<0> friend who's doing a nanotech PHD tried to explain them, but I kind of tune physisits out
<6> They are provably unflawed
<6> Otherwise they don't qualify as methods
<1> Klaim: it's not shared between threads, it can be accessed by any thread, for example the threads that send the rendering to queues have to lock the queues before adding stuff to them
<1> Still, threads don't have to "communicate" to do that
<0> I've never liked mutexes. Always seem like glossing over the problem
<3> Asriel, I know a guy at google that told me that they sometimes had corrupted bits on their hardware because they were processing THAT much information. the very very smallprobability of this happening suddenly became real
<1> True
<0> like stupid management debates where someone gets "the hammer" and only the person with it can talk
<1> Klaim: of course you could consider adding data to the queue and reading it from another thread is communication
<2> yes i understand that but they have to wait each others to get that data is'nt it? so how do you have 100% working?
<0> and you're just sitting there thinking about how much more usefully your time could be applied
<2> MrAshes ok
<1> They don't wait for each other
<2> then it is what i understood
<0> Quantum`` - Doesn't surprise me
<1> Threads (more than one) push the data
<2> they just read?
<1> Another thread pulls it
<1> They're never waiting
<1> And even if the renderer thread is waiting, then it's cause the queue is empty and there's nothing to render, so it's difficult to use all the CPU ;)
<2> ok i think i see the big picture....
<3> but do you see the frame of the pic?
<3> do you see the wall the picture is attached too?
<2> quantum>lol
<1> Quantum``: in my game, the hero is blind
<7> the picture is too big, it covers the wall
<1> It's a first person shooter
<0> if you can avoid writing multithreaded code, do it
<1> It renders really fast
<7> heh
<1> It's a bit black though
<0> alas, the odds of avoiding it are lowering each year
<1> He's deaf too, so there's no sound either
<0> yet the tools "at the coal face" haven't improved in a decade
<3> what about rendering the imagination of the blind hero?
<1> Garden state
<1> He can't imagine anything
<3> hmm :)
<0> if you're blind from birth, your imagination isn't particuarly visual anyway
<7> lol
<2> i guess you'll have to do something like that on Cell processors, isn't it? or maybe it should be simplier?
<1> Yes, good movie
<1> I know
<3> indeed
<1> Klaim: Cell is just a way for IBM to make Sony go bankrupt
<2> lol
<2> but IBM will sell it with it's servers, no?
<1> Yup
<1> But they can afford it
Return to
#c++
or
Go to some related
logs:
#MissKitten
#AllNiteCafe
#php
#linux
bjondina
#squid
#skype
what is paperika
#linux
#chatzone
|
|