World: r3wp

Not really because one major bug on file scheme block me.

ticket #552 in curecode

Steeve virtual blocks scheme still at megashare? I've bad luck trying 
to download.

give me a convenient place and i post it

I can host it for you.

Steeve, if you paste the code to me privately, I can host it.

you don't have the first version i posted Henrik ?

nothing has changed currently

ok, I'll find it again.

ahah...

http://hmkdesign.dk/rebol/r3/idx.r

I'll post on rebdev too.

THNX 2 U both

ok, thanks

I would not currently assume that tasks will eventally correspond 
to threads at all, green or not. They might switch to the microprocess 
model. In any case we'll try to pick the best strategy for REBOL.

In the french BSS, Carl said that the tasks will not use threads.

*BBS

Yeah, threads have been discredited somewhat in the research community 
lately. Perhaps we could go all out with an Erlang-style green process 
model? That would be fun :)

The current public alpha uses OS threads, doesn't it?

And crashes them.

Almost-public :)

Brian, could you create a sub header in R3/protocols for the virtual 
block scheme ?

Sure.

and move all related msg please (Argh...) :)

Oh... excuse me Henrik, you requested it and you could do that too...

Done.

Steeve, I couldn't find how to in help, so I just asked. :-)

Public messages moved. I'll move the private messages when I figure 
out how to list them.

[VBS] Humm, as i stated, performances are bad currently with append, 
it took 1 minute to add 10000 values (166 values by second).

[VBS] But to fetch 10000 values randomly, it took only 0.01 sec (fast)

[VBS] Did you realize that 1 000 000 values can be fetched in a loop 
without bloating the memory in only 1 SEC

[VBS] SORRY, i made a wrong read, it took 1 sec to fetch 10 000 values 
not 1 000 000 but it's quite good too, no ?       -_-'

@BrianH : What are microprocesses ? you mean something like very 
lightweight processes that don't share common memory?

(lightweing in sense that they can be created and destroyed quickly 
and that there can be many of them)

Steeve, your performance measurements are about dead on with what 
Tretbase performance is.

http://www.rebol.net/cgi-bin/rebdev-web.r?msg=577

Here is a fetch of 10,000 records:

>> s: now/precise db/get test d t: now/precise
== 22-Jan-2009/12:13:34.534-6:00
>> difference t s
== 0:00:00.973


Pretty much about  1 second - similiar to what your seeing.  I don't 
think we can get much more performance out of REBOL than that.

Paul: is tretbase already intended for use or still in development?

It is still in development Janko but progressing.

Tretbase is going to be ported to C though.

to C, interesting

this is maybe a good idea to develop something in gihert level language 
to figure out all bits and pieces and algoritms, and then when you 
have a good picture port it into c

Paul, in fact i had the same result than you, i wrote 1 sec to give 
an arround :)

gihrt = higher

Yeah I figured that Steeve.

Janko, the problem is that REBOL at least in R2 doesn't give us the 
control of memory and such as I would like.

did you try 10 000 random access ? is was in that case

Here is the total experience I did Steeve:

>> d: []
== []
>> loop 10000 [append d random 100000]

== [33695 15852 80380 7196 57367 71232 73853 47912 70304 20415 65171 
70632 77767 89530 45257 65786 34935
 70620 90566 92441 23445 26...
>> db/get test d

== [[44 #{00000354} [paul tretter 41]] [45 #{00000368} [paul tretter 
41]] [46 #{0000037C} [paul tretter
41]] [55 #{00000430} [paul ...
>> s: now/precise db/get test d t: now/precise
== 22-Jan-2009/12:13:34.534-6:00
>> difference t s
== 0:00:00.973

Notice my records are only three fields each.

Obviously the size of the record will impact the timing.