Virtual Box implementation

[9600]

[piotr5]

you know, there's a reason why people write papers on the most trivial topics:
even though trivial, it's still a technical advancement nobody did think of earlier.
so, in that spirit, please be more specific with your reply.

for example there exist rocket-driven cars, and they indeed are unreasonably fast.
so quite naturally it makes no sense to put them on the highways.
however, with development of computer-controlled cars, it might make sense in future.
human is incapable of driving at such high speeds, computers might. one obstacle removed.

do you see? all it takes to remove obstacles is to formulate the problem.
eventually someone might come up with a solution.
we wouldn't notice if nobody did state the problem clear enough to connect the two!
so in terms of parallella, as I understood the current hardware allows for 2 connections off board in addition to fpga-connector.
additionally, as I understood, parallella cannot address the whole 4GB range of 32 bits. is that correct?
so what is needed is some sort of software-driven dma-transfer.
i.e. you send a command to another parallella to send you a stream of data.
then this stream is sent on to another parallella through the other connection.
all that is done piece by piece, in chunks of 64KB or something.
do you see any bottleneck in that idea, from the point of view of having 160 core epiphany structure?
as far as I know the only bottleneck is the 160Mb/s to arm-memory.
basically you're limited to emulating x86 with 2x120Mb/s ram bus, but with any amount of cores and memory, right?

as for virtual box, do you see any problem with parallellizing the branch-predictions and coprocessors?
what problems in the area of programming the platform do you see here?
so far I've read most of the forum posts, I can't figure out which posts on programming you are referring to.
or do you mean my memory-model for addressing <10Gb through 32bit? I'm aware it's on the level of GBit network...

[F0T0N]

[piotr5]

in terms of a virtual box, fpga seems to be a slight obstacle as of now, because it doesn't match up with epiphany's speed.
well, that's not really true, it's only single-connection which is slower than on epiphany. so, theoretically it can be fixed by removing this procedual arm-processor altogether.
but seriously, fpga is an obstacle for scalability, as of now. it creates so much heat that you wont get far without worrying about heat-management. you can install a fan, but heat of parallella still is trapped in your room!
besides, why would you need every single of your parallellas to have programmable logic at all? if parallellas communicate through epiphany, no network, no usb, no hdmi are needed! only 3 connections to other boards and one to the main processor!
so what I am suggesting is not to get rid of fpga, just create a new slave-board without it, and sell it as a new product!
well, of course, software first! implementation of both, virtual box and scalability, is needed for testing current fpga code's functionality...

oh, and for clarity's sake, of course x86-emulation is not a scaleable virtual box. you could offer additional processors, but each processor's speed is limited (in the worst-case scenario). similarily memory might be added, but a single thread can still address only 1GB. so, some way of parallell programming is still needed to make use of scalability on x86 programs. however, in terms of graphics-processors there is no such bottleneck in scalability. sadly this direction isn't so well-documented as x86 itself...

[9600]

I thought I'd see if I could get some figures for performance of x86 code running under emulation on ARM. Not surprisingly, there have been experiments with Raspberry Pi, which only has a single older ARM core, and less RAM. But still, this should give us a useful insight into the practicality of running legacy x86 code on ARM.

.

To boot. Not to do anything useful. Simply to boot.

Time and effort is clearly better invested in porting applications (and peripheral drivers!) to new architectures, rather than seeking out plug-and-play magic solutions in a bid to support creaking legacies.

Regards,

Andrew

[piotr5]

thanks for the link. good point to start. but of course it'd be nice if someone actually tried that out on parallella. preferably with os-data stored on sd and swap on net-fs. on my athlon-xp booting into windows takes about half an hour if 1st level cache is disabled (i.e. 266mhz data-bus which probably is what an emulator could be capable of). so the results on the raspberry pi make me quite optimistic. obviously the x86-emu in raspberry pi is only 10 times as slow as my 1.6GHz processor, maybe even less than that if it wouldn't be booting osx at the same time. the next challange would be to actually implement a 1st level cache in the x86 emulator by using the memory located in epiphany. 512KB cache is better than whatever 1st level cache size the raspberry pi has. so I'm wondering, could part of the emulator be compiled for an epiphany core, to make use of that? of course at first you'd need to hand-compile or rather manually link the application in a way that as processor arrives at end of memory, execution switches to the next core. but I guess we need a tool for doing such a thing automatically. most people consider 32kb too small, so this kind of procedual use of epiphany would be pleasing to some. i.e. the linker would need to continue execution in whatever area of data gets used next...

Andrew, I completely agree that time should better be used for solving problems directly. but I wouldn't write this off as waste of time. it is a good test for the hardware and software. if you want to learn parallell programming, you'd better start from scratch instead of building up on your history of highly parallellized signal processing. gcc made some effort to implement some limited amount of automatic parallellization. I'm really surprised nobody here plays around with graphite, for epiphany programs. are there no gcc-developers present? in order to learn something new, you always need to continue what you were doing but with this new stuff in mind, always trying to implement what you've learned. you never will learn anything new if you remain in the old habits, nor if you keep inventing artificial training-exercises for yourself. IMHO investigating in how gcc does compile stuff and trying to improve that is what we all should be doing right now! same with other compilers! so quite naturally this is the best time to learn about how processors work and how to emulate them...

[piotr5]

bump of this thread now that I explained my hardware-side ideas in more detail.

I should also mention, I have an idea for the shape of the scaleable-parallella casing: a 3-sided pyramid, a tetrahedron. maybe the actual board should be that pyramid cut off flat at the base, and the connectors would then be plugged in as inflexible pyramid-parts with another connector at the pyramid-side, a connector that is symmetric in a way that it could be plugged in 3 ways around. preferably without distinction between male and female connector. so you put together 2 such pyramids, touching at one side and fixating the connection at the side's 3 corners. in the center the 2 connectors somehow establish a solid connection same for the connection to the pyramid-base and the parallella itself. or maybe put the parallella into a solid pyramid of that kind. but without replacible pyramid-walls the connectors really need to never distinguish male from female...

disclaimer: I'm just a math student, I don't even need x86 emulation. to me it's interesting to have a scaleable computer. but my point in this thread is: you need scleable computer to keep up with x86 improvements.

[sebraa]

[piotr5]

I don't understand what you see as senseless in my descriptions, I tried to avoid as much mathematical stuff as possible, even replaced the word tetrahedron by pyramid. and don't really know what you mean by "optimal". could you please be a bit more specific? the actual mathematical optimality problem I must solve is the graph-theoretical question:

for fixed node-count find a single-component graph with maximal degree 3, minimal diameter, chromatic number 3 or 4 and non-identical nodes with distance less-equal than 2 must be coloured differently. or alternatively let's say there are 6 colours for the edges: ij€{12,23,13,24,14,34} is the colour of one edge between nodes of colour i and j, respectively. then no neighbouring edges may have the same colour. i.e. neither can the sequence i-j appear twice for the same node (i.e. chromatic number 3 or 4) nor is there any connection i-j-i anywhere in the graph.

my conjecture is, the optimal graph of this kind is the 2-sided tree structure I proposed, with the outermost leafs connected in a way as to shorten the biggest distances. such a tree then is optimized for data-transfer from the 2 tree-roots towards any other node in the tree. in some message above I gave an example of such a double-tree with 10 nodes. this conjecture I must still prove for low node-count, below a million nodes or something.

if my conjecture is true, then it is possible to connect epiphanies on scaleable-parallella or connect epiphany with fpga on current epiphanies, in such a way that each parallella has 4G ram available directly in the address-space, and 10G by programming a dma-transfer on a neighbouring epiphany. this is achieved simply by forming a tree-structure among the parallellas. the tree-structure I propose is not a planar graph, so planar alignment is not possible, neither makes it sense to stack the parallellas one above the other. hence, it must be a 3 dimensional structure. the number of sides is also quickly counted: 3 sides must provide connectors so that the attached structures don't touch eachother, and a 4th side must remain free to provide air for cooling -- this 4th side may not be touched by any of the other structures. the most basic geometrical shape fulfilling these requirements is the regular 3-sided pyramid.

as for the optimal arrangement of this tree of pyramids, it is not unique. optimal arrangement means least amount of space, that's the problem of stacking balls in an optimal way, and as we know there are infinitely many solutions to that problem, when given infinite number of balls. so with this ambiguity it's not possible to say anything about the cooling behaviour. I built a model of the 10-node setup described above, and based on this model it seems to be possible making the unoccupied space form spirals which then can be cooled with the help of 3 fans. but you're right, an actual 3d-drawing and thermal simulation is needed. but without that, attach a fan ontop of each parallella's heatsink, and of course again the heatsink must be located outside of the case. only thing I'm wondering about is if such arrangement wont put too much stress on the cases, when you connect several hundred parallellas this way, each with (power) cables in the ventilation-shafts and each with a fan blowing air down a spiralling pipe...

[piotr5]