🚀 go-pugleaf

If you use the low level kernel message passing, you can get *ABOUT*
10000 messages per seconds... the complex message passing system between
applications (using structured messages) is somewhat slower though.

		-- Benoit
 

In <jazzDI1u41.16H@netcom.com> jazz@netcom.com (David C. Navas) writes:

>From the web site:
>>Q: How fast can messages be sent between applications? 
>>A: We've timed this at about 1000 messages/replies per second. Of course,
>>this will vary with the time you need to spnd actually
>>processing the message, but raw send/recieves are fast. 

>Thank you for caring about the speed of operations like this.  I hope
>you will take the following criticism in the positive vein in which it
>is offered.  :-)

>On the Amiga, under SHADOW, I believe I got upwards of 2500 messages per
>second on a 25Mhz 68030.  This is from memory, and I apologize if it's
>not exactly correct.  However, it was well over the 1000 you've gotten.  I
>suspect there's some work you need to do.

He said messages/replies. The way I read that, and I might be wrong, was
that 2000 messages were being sent, ie 1000 message-reply pairs. Is that
right, or am I misreading?

also they didn't say how much processing of the messages they were doing.

and as you point out in the portion of your message that I clipped,
there's a lot more delivery overhead in a wildly multithreaded
multitasking protected memory system like Be. I'm impressed with 1
millisecond messaging... I admit I'd be impressed with 300 microsecond
delivery even more :-) Be is still in BeTa though :-). Assuming
everything gets compiled on the Metrowerks compiler, they have the
provision for some sort of profiling. I imagine things will be tuned as
they get nearer to release. I know apple often doubles the speed of
certain functions in their "system update X" releases.

BTW: Question for Be...

Are there provisions for profiling on the BE? Perhaps this would be a
good thing to put into the debug server? It'd be cool to have a
(switchable) system level support for profiling.... Also how about
optimizations? If the metrowerks compiler you're using is the same as
the Mac version, there are all sorts of global optimizations available.
What optimization settings are you using for the developer releases?



-- 
Daniel Lakeland: Macintosh Hacker, Mathematics Major, Be computing
"Hairy Guy", NRA Member, and Libertarian. Prevent the government from
disarming, searching, seizing, jailing, beating, and otherwise abusing
your rights! THE 9th AMENDMENT:live its message.

Actually with 2 CPU you can hope to reach better values than with a single
one... the reason is that you can have some balanced processed on both
sides which will not have to context switch at all... the message works
then like a mailbox between the two tasks... just difficult to achieve.

Kernel messages are very critical to our performance... we keep looking
for ways to improve it.

		-- Benoit

In article <umisef.40.30AE344D@halls1.cc.monash.edu.au>,
umisef@halls1.cc.monash.edu.au (Bernd MEYER - Bernie) writes:

> Let me join David in wondering why the number of messages is so small.
> I just did a small test on my linux-laptop. I started two processes that
> were alternately writing into and reading from a named pipe (as in:

This is not the kind of messaging Be times. Messages are addressed packets
of structured data. You create a message, you add typed, named, parameters
(data) to it, you send the message to one of many receivers, the receipient
receives and decodes the message.

There are lower-level primitives in the Be OS, including raw shared memory
plus semaphores, and "ports" which work a lot like message queues. Using
ports, in the simplest fashion, I get 5000 query/reply pairs per second.
This is real-time seconds; I don't know if anything else is happening on
the machine as well (though I doubt it)

I haven't tried shared memory+semaphore, or BMessage (which is probably
what's being quoted) or the direct-to-thread messaging mechanism.

Cheers,

				/ h+




Jon Watte                        Working for Metrowerks, Speaking for myself
h+@metrowerks.com, hplus@bga.com
"I am their leader. I am elected by the people. So I must follow them."

In article <ACD5092596684DB87@jake-6f.ip.realtime.net> hplus@bga.com (Jon Watte) writes:
>From: hplus@bga.com (Jon Watte)
>Subject: Re: Message passing speed on BeBox
>Date: Sun, 19 Nov 1995 16:17:41 -0600

>In article <umisef.40.30AE344D@halls1.cc.monash.edu.au>,
>umisef@halls1.cc.monash.edu.au (Bernd MEYER - Bernie) writes:

>> Let me join David in wondering why the number of messages is so small.
>> I just did a small test on my linux-laptop. I started two processes that
>> were alternately writing into and reading from a named pipe (as in:

>This is not the kind of messaging Be times. Messages are addressed packets
>of structured data. You create a message, you add typed, named, parameters
>(data) to it, you send the message to one of many receivers, the receipient
>receives and decodes the message.

Well, that isn't all that different from sending stuff into a pipe
with 

   fprintf(pipefd,"%d\n",value);

or reading it with 

   fscanf(pipefd,"%d",&value);

I might try sending a sructure through that pipe, instead of having
the printf and scanf functions there. It should speed things up 
tremendously.

>There are lower-level primitives in the Be OS, including raw shared memory
>plus semaphores, and "ports" which work a lot like message queues.

Yep. Same in Unix. Most versions these days provide SysV IPC, which has
all that. I don't know how to use it, though, so I can't time the stuff.

>Using
>ports, in the simplest fashion, I get 5000 query/reply pairs per second.
>This is real-time seconds; I don't know if anything else is happening on
>the machine as well (though I doubt it)

As I mentioned in my previous post, using the Byte Benchmarks and the
new scheduler for linux, you can get more than 30000 cycles on a fast
machine, sending around a single "long" through a pipe.  

Bernie

In article <umisef.51.30B0765F@halls1.cc.monash.edu.au>,
umisef@halls1.cc.monash.edu.au (Bernd MEYER - Bernie) wrote:

> In article <ACD5092596684DB87@jake-6f.ip.realtime.net> hplus@bga.com
(Jon Watte) writes:
> >This is not the kind of messaging Be times. Messages are addressed packets
> >of structured data. You create a message, you add typed, named, parameters
> >(data) to it, you send the message to one of many receivers, the receipient
> >receives and decodes the message.
> 
> Well, that isn't all that different from sending stuff into a pipe

Yes it is.

> I might try sending a sructure through that pipe, instead of having
> the printf and scanf functions there. It should speed things up 
> tremendously.

Be messages are not just structures, they are associative dictionaries
which you can query for information of a certain type. If you just
send a C struct through a pipe you have to know what it is you are
receiving. A BMessage can be asked what it contains. Data is tagged
by keyword and type.

   --- james mccartney    james@astro.as.utexas.edu

In article <48qu77$5jj@menja.ifi.uio.no> stigo@ifi.uio.no (Stig Arne Olsen) writes:

[UNIX IPC]

>I have used them, but never timed them. However, a posting on comp.sys
>unix.programmer once indicated that SYSV IPC (message queues) could
>be somewhere between 3-5 times faster than using the socket calls
>(AF_UNIX for internal comm.).

>But back to the BeOS - I think Benoit S. indicated earlier that you
>could get around 10000 msg/sec by using the low-level calls if I
>understood his article correctly.

Yep, read that one, too. Which made me a bit sad, as that is less than
a third of what you can get in linux _without_ using low level stuff.
Now those "messages" in the Byte Benchmark are not really complicated -
but still......

Bernie

In article <james-2011950941130001@slip-21-7.ots.utexas.edu>,
James McCartney <james@astro.as.utexas.edu> wrote:
>In article <umisef.51.30B0765F@halls1.cc.monash.edu.au>,
>umisef@halls1.cc.monash.edu.au (Bernd MEYER - Bernie) wrote:
>
>> I might try sending a sructure through that pipe, instead of having
>> the printf and scanf functions there. It should speed things up 
>> tremendously.
>
>Be messages are not just structures, they are associative dictionaries
>which you can query for information of a certain type. If you just
>send a C struct through a pipe you have to know what it is you are
>receiving. A BMessage can be asked what it contains. Data is tagged
>by keyword and type.

  Hmm ..  Are there details of the message implementation in the 
BeBook on //www.be.com?  It seems at first glace like you could do
this by preceeding each structure with a structure which describes
that structure in a manner standardized across all applications.

  An interesting alternative method for IPC might be to allow
applications to create a structure in shared memory of the format:
  [control] [fields definition] [record1] [record2]..[recordn]

  Where [control] contained access semaphores, the number of
records in the structure, and pointers to the first and last
valid records (ie, making a circular queue), [fields definition]
contained a globally-understood structure defining the format
of the records, and records1..n were space for structures of the 
type defined in [fields definition].

  An entry for this shared memory structure could be placed in
a globally accessible table so that processes can sync, and once
a "connection" is made writing data to the queue would be as fast
as copying blocks between memory location (with a little overhead
for semaphore management).  It wouldn't be dynamic like the BeOS
messages, so it's not a replacement, but it would be a fast, cute
way of implementing record-based (as opposed to byte-based, like
in a pipe) IPC.

/---\ /---\ /=   /   ttk@rahul.net    CCS ZuulOS Development Labs
  =     =    = /     GCS  d-- H s++: g+(?) p0+(4++) au a! w++ v-?
  =     =    = \     C++++ UBLS++ P+ L+ 3- E+ N++ K !W--- M-- V--
  =     =    =   \   -po+ Y+ t+ 5++ !j R G'' !tv b+ D++(+++) B---
                     e+ u+ h+*>++ f n+(++) y++*

umisef@halls1.cc.monash.edu.au (Bernd MEYER - Bernie) writes:

>In article <ACD5092596684DB87@jake-6f.ip.realtime.net> hplus@bga.com (Jon Watte) writes:
>>From: hplus@bga.com (Jon Watte)
>>Subject: Re: Message passing speed on BeBox
>>Date: Sun, 19 Nov 1995 16:17:41 -0600


>>Using
>>ports, in the simplest fashion, I get 5000 query/reply pairs per second.
>>This is real-time seconds; I don't know if anything else is happening on
>>the machine as well (though I doubt it)

>As I mentioned in my previous post, using the Byte Benchmarks and the
>new scheduler for linux, you can get more than 30000 cycles on a fast
>machine, sending around a single "long" through a pipe.  

Just for comparison, on a SparcStation 10/51, sending a file of size
4194304 as 4-byte messages across a TCP/IP socket (two processes, one
system) took 1.5 seconds. This included dumping the output to /dev/null.
This ain't a terribly scientific measurement, but 700,000 longs/sec is
about what I'd expect from a real system that has 350+ processes running
(though a low load average).

I should expect the BeBox to exhibit at least 4MB/s interprocess communication
bandwidth, since dual 603s are definitely faster than a 50MHz Sparc. If I get
around to it, I'll write an IPC program-pair to test out SysV IPC on the Sparc.
I would expect nearly the same results, if not better, since IPC won't be going
through all the layers of TCP/IP.

Fest3er
-- 
The Microsoft thirty bladed swiss army knife with corkscrew and magnifying lens
[is] inappropriate for all of my word processing needs.

  - Stephanie Evans

In article <murphyn.817001243@orca> murphyn@orca.cig.mot.com (Neal P. Murphy) writes:

>Just for comparison, on a SparcStation 10/51, sending a file of size
>4194304 as 4-byte messages across a TCP/IP socket (two processes, one
>system) took 1.5 seconds. This included dumping the output to /dev/null.
>This ain't a terribly scientific measurement, but 700,000 longs/sec is
>about what I'd expect from a real system that has 350+ processes running
>(though a low load average).

Uh --- did you synchronize those processes? That's the point in sending
the message back and forth --- otherwise you just fill up the socket,
_then_ switch context, empty it again, switch back...Which means you
get possibly hundreds of messages per context switch, which makes this
an unfair comparison.

Bernie

In article <48stbk$pmv@hustle.rahul.net>,
Bill Moyer <ttk@rahul.net> writes:

> An entry for this shared memory structure could be placed in
> a globally accessible table so that processes can sync, and once
> a "connection" is made writing data to the queue would be as fast

Pipes are connected. This scheme you describe is connected. BMessages, on
the other hand, are connectionless and can be posted to whetever BReceiver
you want (there's a BRoster of them, even)

Cheers,

				/ h+




Jon Watte                        Working for Metrowerks, Speaking for myself
h+@metrowerks.com, hplus@bga.com
"I am their leader. I am elected by the people. So I must follow them."