Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Billy

Pages: [1] 2 3 ... 12
1
Suggestions / Re: GPGPU acceleration?
« on: April 30, 2017, 05:35:51 PM »
So there would be a fixed set of these node functions that, arranged in different tree structures, produce different bot behaviours? With a pre-written kernel for each function?

I was thinking more that the code in a node could change but all bots in a species would share the tree structure and code so you could go wide that way, but using preset nodes works, too.

Why would that be easier for a GPU than DNA as it is? If the node code can mutate, wouldn't you run into the same problem of divergence?

2
Darwinbots3 / Re: Bot testbed
« on: April 29, 2017, 08:31:41 AM »
Not sure if this is the right place to report it, but I woke my computer from sleep to find this error message:

Code: [Select]
RootLevelException = {
    Description = "SharpDX.SharpDXException",
    Message = "Unknown error (HRESULT = 0x88760868)",
    Source = "System.Windows.Forms.ControlMarshaledInvoke",
    Stack Trace = {
        File = "\Modules\Darwinbots3\Bot.Testbed\Main.cs:140:17",
        File = "\Modules\Darwinbots3\Bot.Testbed\Renderer.cs:109:13",
        File = "\Modules\Darwinbots3\Bot.Testbed\Renderer.cs:149:17",
    },
    Data = {
        radiiOut = {
            0 = "0.6294419442 //0x3FE424636EA17648",
            1 = "0.6594149415 //0x3FE519ED5D06C18A",
            2 = "0.6893879388 //0x3FE60F774B6C0CCB",
            3 = "0.7193609361 //0x3FE7050139D1580D",
            4 = "0.7493339334 //0x3FE7FA8B2836A34E",
            5 = "0.7793069307 //0x3FE8F015169BEE91",
            6 = "0.809279928 //0x3FE9E59F050139D2",
            7 = "0.8392529253 //0x3FEADB28F3668513",
            8 = "0.8692259226 //0x3FEBD0B2E1CBD055",
            9 = "0.8991989199 //0x3FECC63CD0311B96",
            10 = "0.9291719172 //0x3FEDBBC6BE9666D9",
            11 = "0.9591449145 //0x3FEEB150ACFBB21A",
            12 = "0.9891179118 //0x3FEFA6DA9B60FD5B",
            13 = "1.0190909091 //0x3FF04E3244E3244E",
            14 = "1.0490639064 //0x3FF0C8F73C15C9EF",
            15 = "1.0790369037 //0x3FF143BC33486F90",
            16 = "1.109009901 //0x3FF1BE812A7B1531",
            17 = "1.0790369037 //0x3FF143BC33486F90",
            18 = "1.0490639064 //0x3FF0C8F73C15C9EF",
            19 = "1.0190909091 //0x3FF04E3244E3244E",
            20 = "0.9891179118 //0x3FEFA6DA9B60FD5B",
            21 = "0.9591449145 //0x3FEEB150ACFBB21A",
            22 = "0.9291719172 //0x3FEDBBC6BE9666D9",
            23 = "0.8991989199 //0x3FECC63CD0311B96",
            24 = "0.8692259226 //0x3FEBD0B2E1CBD055",
            25 = "0.8392529253 //0x3FEADB28F3668513",
            26 = "0.809279928 //0x3FE9E59F050139D2",
            27 = "0.7793069307 //0x3FE8F015169BEE91",
            28 = "0.7493339334 //0x3FE7FA8B2836A34E",
            29 = "0.7193609361 //0x3FE7050139D1580D",
            30 = "0.6893879388 //0x3FE60F774B6C0CCB",
            31 = "0.6594149415 //0x3FE519ED5D06C18A",
            32 = "0.6294419442 //0x3FE424636EA17648",
            33 = "0.5994689469 //0x3FE32ED9803C2B07",
            34 = "0.5694959496 //0x3FE2394F91D6DFC5",
            35 = "0.5395229523 //0x3FE143C5A3719483",
            36 = "0.509549955 //0x3FE04E3BB50C4941",
            37 = "0.4795769577 //0x3FDEB1638D4DFC00",
            38 = "0.4496039604 //0x3FDCC64FB083657E",
            39 = "0.4196309631 //0x3FDADB3BD3B8CEFA",
            40 = "0.3896579658 //0x3FD8F027F6EE3877",
            41 = "0.3596849685 //0x3FD705141A23A1F3",
            42 = "0.3297119712 //0x3FD51A003D590B70",
            43 = "0.2997389739 //0x3FD32EEC608E74ED",
            44 = "0.2697659766 //0x3FD143D883C3DE6A",
            45 = "0.2997389739 //0x3FD32EEC608E74ED",
            46 = "0.3297119712 //0x3FD51A003D590B70",
            47 = "0.3596849685 //0x3FD705141A23A1F3",
            48 = "0.3896579658 //0x3FD8F027F6EE3877",
            49 = "0.4196309631 //0x3FDADB3BD3B8CEFA",
            50 = "0.4496039604 //0x3FDCC64FB083657E",
            51 = "0.4795769577 //0x3FDEB1638D4DFC00",
            52 = "0.509549955 //0x3FE04E3BB50C4941",
            53 = "0.5395229523 //0x3FE143C5A3719483",
            54 = "0.5694959496 //0x3FE2394F91D6DFC5",
            55 = "0.5994689469 //0x3FE32ED9803C2B07",
            56 = "0.6294419442 //0x3FE424636EA17648",
            57 = "0.6594149415 //0x3FE519ED5D06C18A",
            58 = "0.6893879388 //0x3FE60F774B6C0CCB",
            59 = "0.7193609361 //0x3FE7050139D1580D",
            60 = "0.7493339334 //0x3FE7FA8B2836A34E",
            61 = "0.7793069307 //0x3FE8F015169BEE91",
            62 = "0.809279928 //0x3FE9E59F050139D2",
            63 = "0.8392529253 //0x3FEADB28F3668513",
            64 = "0.8692259226 //0x3FEBD0B2E1CBD055",
            65 = "0.8991989199 //0x3FECC63CD0311B96",
            66 = "0.9291719172 //0x3FEDBBC6BE9666D9",
            67 = "0.9591449145 //0x3FEEB150ACFBB21A",
            68 = "0.9891179118 //0x3FEFA6DA9B60FD5B",
            69 = "1.0190909091 //0x3FF04E3244E3244E",
            70 = "1.0490639064 //0x3FF0C8F73C15C9EF",
            71 = "1.0790369037 //0x3FF143BC33486F90",
            72 = "1.109009901 //0x3FF1BE812A7B1531",
            73 = "1.0790369037 //0x3FF143BC33486F90",
            74 = "1.0490639064 //0x3FF0C8F73C15C9EF",
            75 = "1.0190909091 //0x3FF04E3244E3244E",
            76 = "0.9891179118 //0x3FEFA6DA9B60FD5B",
            77 = "0.9591449145 //0x3FEEB150ACFBB21A",
            78 = "0.9291719172 //0x3FEDBBC6BE9666D9",
            79 = "0.8991989199 //0x3FECC63CD0311B96",
            80 = "0.8692259226 //0x3FEBD0B2E1CBD055",
            81 = "0.8392529253 //0x3FEADB28F3668513",
            82 = "0.809279928 //0x3FE9E59F050139D2",
            83 = "0.7793069307 //0x3FE8F015169BEE91",
            84 = "0.7493339334 //0x3FE7FA8B2836A34E",
            85 = "0.7193609361 //0x3FE7050139D1580D",
            86 = "0.6893879388 //0x3FE60F774B6C0CCB",
            87 = "0.6594149415 //0x3FE519ED5D06C18A",
            88 = "0.6294419442 //0x3FE424636EA17648",
            89 = "0.5994689469 //0x3FE32ED9803C2B07",
            90 = "0.5694959496 //0x3FE2394F91D6DFC5",
        },
    },
}

3
Suggestions / Re: GPGPU acceleration?
« on: April 29, 2017, 08:30:07 AM »
I get I am not good with words; it is not my native.
However point still stands that no one figured it out. It would have been perfect architecture because each master process can just assign threads or processes or whatever to different sized CPUs. Or just hack it into a programming language. Something like "start a new n speed thread"

Not sure it's a case of figuring out how (though I don't know much about electronics), rather proving that it's worth doing. Most things can be done well enough on a CPU and/or GPU. Maybe having a few smaller cores is no better than having a single extra full-size core.

4
Suggestions / Re: GPGPU acceleration?
« on: April 29, 2017, 08:20:50 AM »
I guess you're probably right. I was thinking that if 90% of the bots have very similar DNA and are doing exactly the same activity, there would be very little divergence and it would effectively be SIMD.  I'd still like to make a prototype, maybe with some minimal language rather than DNA, so I can compare the performance with that on a CPU.

I don't think it's impossible with a bit of ingenuity to come up with something, but it's a bit awkward.  At their core, bots have 1000 inputs (their memory) and 1000 outputs (their memory after storing stuff in to it).  GPUs don't really like mapping inputs to outputs in the large scale like that.  They tend to be more comfortable mapping a small fixed number of inputs to 1 output over and over in parallel, and doing multiple passes if they need to.

One idea: I could imagine a DNA language built around the idea of smaller DNA programs feeding to each other.  Like, imagine a neural network, but instead of a sum and logistic function each node is a small program.  If each small program had 16 inputs, say, and a single output that fed on to the next layer of nodes, each node could be executed massively in parallel using the GPUs quite nicely.  I don't know if this would be even remotely efficient, but it would sort of map to how the hardware works at least.

So there would be a fixed set of these node functions that, arranged in different tree structures, produce different bot behaviours? With a pre-written kernel for each function?

5
Suggestions / Re: GPGPU acceleration?
« on: April 28, 2017, 01:54:54 PM »
Do not care about what MIMD stands for. In general a lot of small CPU cores compute a lot of small parallel instruction sets really quickly. Then have one huge chip like the new Intel shit super cooled for large instruction sets.

MIMD just means that each core runs its own program with its own data, so yeah, that pretty much what I was getting at. I guess the issue with that is expense. Each core having its own control unit would cost silicon relative to a GPU, so it might work out better to just use the larger, faster cores in today's CPUs. Perhaps not though, it would be very handy for massively parallel problems where GPUs can't be used.

By the way, 'instruction set' has a specific meaning that is different, I think from how you're using the term. A CPU has one instruction set, which is just the instructions that it can process (e.g. add, load, store, etc.). When source code is compiled, it is translated into the instruction set of the platform it's targeting (e.g., x86-64 or ARM). Each platform has its own assembly language too, where you can write a program directly using the instructions from the instruction set of that platform.

6
Suggestions / Re: GPGPU acceleration?
« on: April 28, 2017, 09:30:25 AM »
Problem is GPUs only benefit when they can do the same operation (add, multiply, etc.) in parallel.  Even if you put the DNA on the GPUs somehow, you still can't execute more than one DNA program at a time.

It's a problem of SIMD vs. MIMD.  GPUs need SIMD to overcome the additional cost of transferring the data to/from the GPU and starting up a processing batch, but most of Darwinbots is either SISD or MIMD.  The DNA execution is MIMD, certainly.  The physics has passes of MIMD but then everything bottlenecks in places through a SISD section.  In that sort of problem, CPUs are still king.

I guess you're probably right. I was thinking that if 90% of the bots have very similar DNA and are doing exactly the same activity, there would be very little divergence and it would effectively be SIMD.  I'd still like to make a prototype, maybe with some minimal language rather than DNA, so I can compare the performance with that on a CPU.

Botsareus: what kind of thing do you think would be better? A chip with lots of simple MIMD cores?

7
Darwinbots3 / Re: Bot testbed
« on: April 27, 2017, 06:56:20 PM »
Mine is more concise though!

I think it was when I was fiddling with the number on the last line that is now 30, I can't seem to reproduce it now unfortunately.

8
Suggestions / Re: GPGPU acceleration?
« on: April 27, 2017, 06:40:37 PM »
Couldn't kernels read tokenised DNA code from one buffer, memlocs from another, and interpret the DNA? Writing the new memloc values to a third buffer, perhaps. There is a lot of branching, which would reduce the benefit from SIMD processors, but maybe this could be reduced by grouping similar bots. Most bots spend the vast majority of their time doing one thing, from my experience (at least in evosims), like searching or spinning, so this might just work.

9
Suggestions / GPGPU acceleration?
« on: April 27, 2017, 10:04:56 AM »
I know it's pain to get working, but a simulation with many bots seems like an ideal problem for opencl or similar. One job for each bot, and perhaps even grouping similar bots into warps for SIMD execution on Nvidia chips. You wouldn't necessarily have to move much data between main memory and GPU memory if you don't need to observe the simulation in real time.

I've only dabbled with GPU programming though (circle detection in images), so maybe it's not as well suited as it seems. I am aware that it would take a lot of effort to port all of the DB simulation code to opencl, what with the physics, DNA interpretation, reproduction mutation... Maybe I'll try making something similar from scratch over the summer, specifically geared towards GPGPU execution.

10
Darwinbots3 / Re: Bot testbed
« on: April 27, 2017, 09:44:36 AM »
Nice work, Nums! Took you long enough :P

Here's a quick 'swimmer' I threw together:

Code: [Select]
const myage 360
{ *myage 1 add myage store } call
//{ 0 myage store } call
*numspindles { dup *numspindles 2 div sub abs     *myage *numspindles 2 div mod sub abs 30 mul 100 swap sub 1000 add   swap store } loop

Sometimes it bugs out and you have to uncomment the line and recomment it to make it work.

11
Darwinbots Program Source Code / Re: Status of IM mode
« on: September 30, 2014, 06:24:42 PM »
Right, didn't know about that. Here you go!

Code: [Select]
Tag:FileName:User
~~~

                                             :Newton.txt:
                                             :Alga_Minimalis.txt:
                                             :Callidus(F1)(Shen)-05.04.05.txt:MacadamiaNuts

12
Darwinbots Program Source Code / Re: Status of IM mode
« on: September 30, 2014, 06:13:46 PM »
Just click on robot tag information and paste it here directly.
Code: [Select]
{"cycle":15197000,"simId":"29-09-2014 00-10-52","unixtime":1412115176,"width":192000,"height":144000,"population":[{"botName":"Alga_Minimalis.txt","count":223,"repopulating":true},{"botName":"Newton.txt","count":307}]}
That what you're looking for?

13
Darwinbots Program Source Code / Re: Status of IM mode
« on: September 30, 2014, 06:11:18 PM »
I think I broke it somewhere, I restarted the server. Even after restarting, I can't manage to run that graph. Seems to be quite big.

(minor note, I'm using the inbuild python webserver which is not recommended to be run in production, just for development, performance won't be amazing to say the least, I plan to switch that to an actual webserver)

edit: restarted the webserver to be clear.

Sim 4770 got 142889 points to be drawn on a graph. Didn't think I had to limit the amount of points drawn for a sim graph. :|

The population graph in the actual sim has only 950 d.p.

14
Darwinbots Program Source Code / Re: Status of IM mode
« on: September 30, 2014, 06:08:28 PM »
Hmmm... now it does not seem to load at all. (Maybe I did not wait enough) What factors play a role on how long java script is supposed to load? Does Billy have an a graph update interval of 1?
No, it is default.

15
Darwinbots Program Source Code / Re: Status of IM mode
« on: September 29, 2014, 05:45:56 PM »
Awesome, thanks Peter, I'll update.

Pages: [1] 2 3 ... 12