Subject: Grid computing architecture w/ 9P + Java

Hi folks,

I'm currently playing around with some ideas for a new (or perhaps
very old ? ;-o) computing architecture, based on 9P + Java.
It's a bit of old Burroughs MF, a bit of Ambric and a bit ja Java ;-o

The idea bind: have a bunch of tiny Java machines (not the whole 
JEE bloat, just a very small set of basic classes) which talk to
each other through filesystems (of course via 9P ;-P).

At the moment, I'm doing a massive trim-down of Jamvm+classpath,
leaving in only what's needed for a small hello-world. 

Later, I'll create an minimalistic embedded firmware for small 
devices which then should run in an grid.

If anyone's interested, just let me know.

cu
--

-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info <at> metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: image/memimage speed

>> what I'm seeking is a way to avoid the unloadimage() call in nn.c, if
>> that's possible - which, by my understanding of the manual and code,
>> is not.
>> alternatively I could try drawing the memimage to the screen, which I
>> did not find possible directly, only by converting it to an image.
>> any ideas?
>>
>> sorry if I'm missing the obvious.
>>
> 
> mostly everything here is now understood by me. sorry for the noise.

i think this is a good point.  reading from the frame buffer can
be deathly slow on a lot of modern video cards.  you're seeing a
factor of 60.  it might be a good idea to keep a copy of the
framebuffer in kernel memory.

i have been using a write-combining framebuffer for about four
months.  (implemented for the x86 architechture via the pat
bits in the page table.)  it has made drawing (writes to the 
framebuffer) much faster, but, since reads from the frame buffer
are slow for different reasons, it doesn't help at all for operations
like unhiding windows.

- erik

Re: image/memimage speed

can you report timings on the xscreensaver hacks (link at bottom)?

they have a "benchmarking" option -b S which lets you see how many fps
they're doing:

mk all; for (i in 8.*) { echo -n $i^': '; $i -b 5 }

would run each hack for 5 seconds and let you know what their fps is.

i used to get incredible fps reports in parallels, where everything
was in memory and read backs were fast.

andrey

http://mirtchovski.com/p9/xscr/xscr.tgz

> i think this is a good point.  reading from the frame buffer can
> be deathly slow on a lot of modern video cards.  you're seeing a
> factor of 60.  it might be a good idea to keep a copy of the
> framebuffer in kernel memory.
>
> i have been using a write-combining framebuffer for about four
> months.  (implemented for the x86 architechture via the pat
> bits in the page table.)  it has made drawing (writes to the
> framebuffer) much faster, but, since reads from the frame buffer
> are slow for different reasons, it doesn't help at all for operations
> like unhiding windows.
>
> - erik
>

Re: image/memimage speed

> can you report timings on the xscreensaver hacks (link at bottom)?

sure.  a few of the programs didn't seem to work (delayscreen
and polydominoes).  mountain, sphere and spirograph seemed
to hum right along.

- erik

; cat '#P/archctl'
cpu AMD64 2604 pge
pge on
coherence mfence
cmpswap cmpswap486
i8253set on

; cat /dev/wsys/^`{cat /dev/winid}^/wctl
         60         505         765        1034 current visible 

8.anemone: fps: 30.796417
8.anemotaxis: fps: 25.595581
8.attraction: fps: 55.993117
8.blaster: fps: 71.190817
8.boxfit: fps: 20.596372
8.ccurve: fps: 0.999865
8.cloudlife: fps: 22.795733
8.coral: fps: 70.787094
8.critical: fps: 151.975499
8.decayscreen: fps: 0.000000
8.deco: fps: 0.199968
8.deluxe: fps: 14.197528

Subject: Re: Grid computing architecture w/ 9P + Java

On 12/1/08, Enrico Weigelt <weigelt <at> metux.de> wrote:
>
> Hi folks,
>
>
> I'm currently playing around with some ideas for a new (or perhaps
> very old ? ;-o) computing architecture, based on 9P + Java.
> It's a bit of old Burroughs MF, a bit of Ambric and a bit ja Java ;-o
>
> The idea bind: have a bunch of tiny Java machines (not the whole
> JEE bloat, just a very small set of basic classes) which talk to
> each other through filesystems (of course via 9P ;-P).
>
> At the moment, I'm doing a massive trim-down of Jamvm+classpath,
> leaving in only what's needed for a small hello-world.
>
> Later, I'll create an minimalistic embedded firmware for small
> devices which then should run in an grid.
>
>
> If anyone's interested, just let me know.
>
>

Hi

That is very cool I am doing something similar ( I think ).
In hugs (haskell interpreter) there are some things that relies on
loadable modules. I created a plumber call and it launches a handler
for some of those things.

Subject: Re: Grid computing architecture w/ 9P + Java

Ever heard of Inferno? Or are you using java purely for the
masochistic pleasure?

uriel

On Mon, Dec 1, 2008 at 1:40 AM, Enrico Weigelt <weigelt <at> metux.de> wrote:
>
> Hi folks,
>
>
> I'm currently playing around with some ideas for a new (or perhaps
> very old ? ;-o) computing architecture, based on 9P + Java.
> It's a bit of old Burroughs MF, a bit of Ambric and a bit ja Java ;-o
>
> The idea bind: have a bunch of tiny Java machines (not the whole
> JEE bloat, just a very small set of basic classes) which talk to
> each other through filesystems (of course via 9P ;-P).
>
> At the moment, I'm doing a massive trim-down of Jamvm+classpath,
> leaving in only what's needed for a small hello-world.
>
> Later, I'll create an minimalistic embedded firmware for small
> devices which then should run in an grid.
>
>
> If anyone's interested, just let me know.
>
>
> cu
> --

Re: image/memimage speed

cool, thanks!

those do almost everything: loadimage() from bytes, drawing onto the
screen using itself as a source, drawing primitives (lines and
circles), alpha blending (glenda and hyperglenda) as well as
unloadimage() for the case where the screen is being resized.

i'll try to dig out a parallels installation tomorrow to compare your
results with.

andrey

> sure.  a few of the programs didn't seem to work (delayscreen
> and polydominoes).  mountain, sphere and spirograph seemed
> to hum right along.
>
> - erik
>

Re: image/memimage speed

Minor gripe as a graphics person - I loathe frames per second as a  
performance measure.  Because of the inverse you can't really compare  
the numbers.  Consider the difference in improvement between 1fps and  
2fps compared to 29fps and 30fps.  Both improve by 1fps, but they  
represent dramatically different performance gains.

If you can at all, report milliseconds per frame, ideally with fixed  
system overhead removed.

The only time fps is appropriate is if you're targetting your v-blank  
rate.

Yes, I've been reviewing too many papers with bar charts of gps  
measures lately...

Paul

On Nov 30, 2008, at 6:35 PM, erik quanstrom <quanstro <at> quanstro.net>  
wrote:

>
>> can you report timings on the xscreensaver hacks (link at bottom)?
>
> sure.  a few of the programs didn't seem to work (delayscreen
> and polydominoes).  mountain, sphere and spirograph seemed
> to hum right along.
>
> - erik
>
> ; cat '#P/archctl'

Subject: Re: Grid computing architecture w/ 9P + Java

On Nov 30, 2008, at 4:40 PM, Enrico Weigelt wrote:
> Hi folks,
>
>
> I'm currently playing around with some ideas for a new (or perhaps
> very old ? ;-o) computing architecture, based on 9P + Java.
> It's a bit of old Burroughs MF, a bit of Ambric and a bit ja Java ;-o
>
> The idea bind: have a bunch of tiny Java machines (not the whole
> JEE bloat, just a very small set of basic classes) which talk to
> each other through filesystems (of course via 9P ;-P).

But what's next? Do you have a specific application for these things
in mind?

Besides, Inferno seems to be delivering much more on the
original Java promise, anyway. So why not use it instead?
Or do you really plan to take advantage of the intricacies
of the VM?

Thanks,
Roman.

P.S. Speaking of Inferno -- I have always wanted to run it
natively on these puppies:
     http://www.sunspotworld.com/

How to implement a moral equivalent of automounter in Plan9?

Hi Guys!

I've been trying to implement a "lazy bind/mount" in Plan9 and it  
dawned on
me that I don't really know any way of modifying calling process's  
namespace
on-demand. In a automounter-like style.

Now, before you tell me that I shouldn't be doing it (well, may be I  
shouldn't, but
please keep reading ) let me give you a classical example of what
I'm after.

Consider a way /net is set up on Solaris as an automounter map. Anytime
there's any access requesting /net/≤machine name>/<nfs exports>/files...
the namespace of the calling process gets modified because of the
automounter issuing an NFS mount.

Now, if I want the moral equivalent of the above to happen every time
I access /n/sources/plan9/sys/src/cmd/cpu.c on Plan9 I can have a
synthetic fileserver mounted on /n/ and doing the right thing. But that
will not make the following entry be added to my namespace:
     mount '#s/sources' /n/sources

So, the question is: am I missing something really obvious here,
or is writing a kernel driver that really does modify a namespace the
only way to go here?

Thanks,
Roman.