mORMot Open Source

Any progress on this side? (about the "metadata" endpoint of the mORMot server)
Because then an auto generator could be included in the SMS IDE itself, which can update/create
the client side classes e.g. from a menu option.
The best would be to have full metadata, so if a remote function returns an object, to have a lightweight
client side class generated too for this object (maximum type safety, code completion, etc).

Side note: DataSnap does not offer full metadata for the proxy generators, so only simple function wrappers
can be made . I probably need to make my own metadata retrieval for DS because of this, in order to be able
to generate DS wrappers for the SMS IDE. So maybe we can share some work/ideas etc to get an universal
metadata system? (I know, DS is a competitor but SMS should support as much RPC servers as possible, and this
way we can at least add full mORMot support in the SMS IDE soon too )

No, it is really low level binary TCP connection! (I made a Delphi implementation so I can know it )
With WinSocks you can do the same, because you can send data from client to server and from server to client via the connection handle anytime you want.
(you only need to actively check and wait for incoming data on the client side, I made a single thread for this which can wait for 64 connection at once).
So for Delphi, there is no real benefit to use WebSockets for duplex communication (can be done already, nothing really new) between Delphi server and Delphi clients.

However, we probably gonna use WS in Delphi too, because then we only need ONE http server port for both html4 clients and binary communication for html5 and Delphi clients .

Can you make a demo implementation with mORMot and RTC and RemObjects SDK/Data Abstract?
So I can compare mORMot against theses types?

My timing was correct :-) I tested it several times, even using QueryPerformanceCounter (TStopWatch) instead of millisecondspan.
But I use SQL Server 2008 R2, so probably it has some kind of caching on its own (not ADO generic)?

I think timing is also dependent on amount of null/integer/string data, because my little bit slower SynOleDb test had a lot of string data (which is converted from UTF8 in SynOleDB??).

By the way: SynOleDB seems to have much higher network usage! It used several MB/s during data retrieval, but ADO had much lower amount, like 100Kb/s?? Maybe some kind of compression? I read all column data to be sure everything is fetched.

No, in fact it is much easier/simpler than ScaleMM2 (I did not like the complexity of ScaleMM2)

How much faster is this kernel mode? Do you have any numbers? (response time, throughput, etc)

I fixed it (in a D7 portable edition :-) ) by changing "record" to "object"
(committed in SVN now)

Status update: Tried some offsets to disalign, but no succes. I think I just must prevent too much "lookups" (needs L1/L2 cache fetches, or worse: memory fetch).
Instead of nice structure and good "code smell" I'll have to use speed hacks and/or more (packed) data in the header for intelligent reallocs (I must determine the type: small, medium and large, and even worse: check the thread owner). I have some ideas for it, but this need some restructure...

I have already made a simple pre-realloc check: if new size is smaller but greater than 1/4 of current size, nothing has to be done (no thread owner or type check). Now a realloc test is only slightly slower than (asm optimized!) FastMM/D2010.

I have some slow performance in my code:
https://picasaweb.google.com/lh/photo/G … directlink
https://picasaweb.google.com/lh/photo/Q … directlink

Why are these lines below so slow? (more than 100 CPU cycles)
    if NativeUInt(pm.OwnerBlock) and 1 <> 0 then 
and:
    if ot = PBaseThreadMemory(FCacheSmallMemManager) then

Maybe because of L1/L2 cache fetch? (FCacheSmallMemManager is located in current object, maybe needs to fetch it?).
How can this be optimized?
(these 2 lines consumes most of the time)

========================================

function TThreadMemManager.ReallocMem(aMemory: Pointer;
  aSize: NativeUInt): Pointer;
var
  pm: PBaseMemHeader;
  ot: PBaseThreadMemory;
begin
  if FOtherThreadFreedMemory <> nil then
    ProcessFreedMemFromOtherThreads;

  pm := PBaseMemHeader(NativeUInt(aMemory) - SizeOf(TBaseMemHeader));
  //check realloc of freed mem
  if (pm.Size and 1 = 0) then
  begin
    if NativeUInt(pm.OwnerBlock) and 1 <> 0 then 
//lowest bit is mark bit: medium mem has ownerthread instead of ownerblock (temp. optimization trial)
//otherwise slow L1/L2 fetch needed in case of "large" distance
    begin
      ot := PBaseThreadMemory( NativeUInt(pm.OwnerBlock) and -2);  //clear lowest bit
      if ot = PBaseThreadMemory(FCacheMediumMemManager) then
        Result := FCacheMediumMemManager.ReallocMem(aMemory, aSize)
      else
        Result := ReallocMemOfOtherThread(aMemory, aSize);
    end
    else
    begin
      ot := pm.OwnerBlock.OwnerThread;

      if ot = PBaseThreadMemory(FCacheSmallMemManager) then
        Result := FCacheSmallMemManager.ReallocMem(aMemory, aSize)
  //    else if ot = PBaseThreadMemory(FCacheMediumMemManager) then
  //      Result := FCacheMediumMemManager.ReallocMem(aMemory, aSize)
      else if ot = PBaseThreadMemory(FCacheLargeMemManager) then
        Result := FCacheLargeMemManager.ReallocMemWithHeader(aMemory, aSize)
      else
        Result := ReallocMemOfOtherThread(aMemory, aSize);
    end
  end
  else
    Error(reInvalidPtr);
end;

Sorry, it was a quick test
FastMM is 100% (time), so anything above is bad (like the first test), anything below is better (less is less time, so faster, is better )

Checked in better large mem handling, now ScaleMM2 is 20% faster in FastCodeMMChallenge :-)

Average Speed Performance: (Scaled so that the winner = 100%)
  DelphiInternal :   79,7
  ScaleMem    :  100,0

Still some improvements possible, because some test results are too bad (will investigate and "fix" them)

Compiles and runs fine on D2007 too now
Extra checks added, new extensive test running and going fine so far

Latest version seems to work OK now (added medium mem CheckMem functions: found a couple of nasty bugs with it!)
Also unit test added.
http://code.google.com/p/scalemm/source/browse/trunk

It only supports mem < 2Gb and no interthread mem support and no mem leak support yet.
And some more optimizations and cleanup needed...

30M alloc/realloc/free (small mem, 10 - 120bytes), 1 thread
FastMM    = 4376ms
ScaleMM2 = 1651 (still too high, can be optimized further, ScaleMM1 has about 1100ms)

30M alloc/realloc/free (medium mem, 10kb - 80kb), 1 thread
FastMM    = 58206ms (!), with no resize (+10bytes) = 2302ms
ScaleMM2 = 2326ms

for j := 0 to 1000 do
  for i := 0 to 10000 do
      p1 := GetMemory(10);
      p2 := GetMemory(40);
      p3 := GetMemory(80);
      p1 := ReallocMemory(p1, 30);
      p2 := ReallocMemory(p2, 60);
      p3 := ReallocMemory(p3, 120);
      FreeMemory(p1);
      FreeMemory(p2);
      FreeMemory(p3);

for j := 0 to 1000 do
  for i := 0 to 10000 do
      p1 := GetMemory(10 * 1024);
      p2 := GetMemory(40 * 1024);
      p3 := GetMemory(80 * 1024);
      p1 := ReallocMemory(p1, 10 * 1024 + 10);
      p2 := ReallocMemory(p2, 40 * 1024 + 100);
      p3 := ReallocMemory(p3, 80 * 1024 + 10);
      FreeMemory(p1);
      FreeMemory(p2);
      FreeMemory(p3);

Version 2 almost working, ScaleMM1 works on top of v2 now.
(ScaleMM2 needs 16byte header + minimum alloc size of 32 bytes, so too much overhead for small blocks. ScaleMM1 is for small mem (<2kb) and ScaleMM2 for medium (<1Mb) and larger is direct VirtualAlloc/free)
http://code.google.com/p/scalemm/source … caleMM.pas
http://code.google.com/p/scalemm/source … aleMM2.pas

Some "small" problems needs to be fixed like backwards free block scanning, so you'll get "out of memory" in intensive tests.
And of course the necessary optimizations, cleanup, documentation etc.

Speed of ScaleMM1 is about 1100ms and ScaleMM2 about 2400ms (30M allocs/reallocs/free). So small memory allocs is faster than medium.

PS: ABA problem needs to be fixed too, will do this soon

Yes, ScaleMM version 1 works on top of FastMM, so large allocations (or when ScaleMM needs more mem) ar locked by FastMM. But all small blocks etc are processed per thread so no locking at all!

Because of the FastMM lock dependency I am making a large block allocator. This allocator is fully dynamic and it seems so good (?) it could also be used for small blocks. So I am thinking to use it as a complete allocator (no real difference between small or medium mem). Or if the speed is not good enough to use ScaleMM1 on top of ScaleMM2 :-).

I really would like to get rid of FastMM locking to get full scaling: this is the future (multi cores, OTL, AsyncCalls, etc)!

Btw: I hope I solved a nasty bug in ScaleMM2 yesterday evening, so I can test/develop it further.

Intel Core2 Quad core Q8300 @ 2.5Ghz

4B
1 = 47,83 nanoseconds per cycle
2 = 58,80 nanoseconds per cycle
4 = 124,68 nanoseconds per cycle
8 = 128,21 nanoseconds per cycle

8B
1 = 56,61 nanoseconds per cycle
2 = 73,01 nanoseconds per cycle
4 = 146,73 nanoseconds per cycle
8 = 146,73 nanoseconds per cycle

8BV
1 = 54,40 nanoseconds per cycle
2 = 75,75 nanoseconds per cycle
4 = 177,40 nanoseconds per cycle
8 = 222,44 nanoseconds per cycle

So 4B seems the fastest

Btw: I almost have my new ScaleMM algoritm ready, only need to fix some bugs (to have a working POC, fully working needs some more time)

I do not think this is true: if what you say is true, I would not need a Sleep() on a "simple" CAS instruction, because it would be completed (very) fast.
It seems however it can be interrupted, so it keeps a lock quite long: I got a race condition, it burned my CPU and I had to wait forever.

I thought (or hoped) a LOCK would not be interupted by a context switch, but it does...
(was more or less a dirty test)

So I did a quick but real test, the following gives the best results:

  ia: array of Integer;
  ...
  for l := 0 to 1000 do
  for i := 0 to 10000 do
  begin
    j := ia[i];
    k := j+1;
    while not CAS32(j, k, ia[i]) do
    begin
      if not SwitchToThread then
        Sleep(0);
      j := ia[i];
      k := j+1;
      if CAS32i(j, k, ia[i]) then
        Break
      else
         Sleep(1);
    end;
  end;

Timing results:
Testing with 1 threads...
Average: 182
Testing with 2 threads...
Average: 214
Testing with 3 threads...
Average: 260
Testing with 4 threads...
Average: 279
Testing with 8 threads...
Average: 426
Testing with 16 threads...
Average: 777

SwitchToThread gives slightly better results if thread count > core count (more efficient to switch to thread on same core).
If I don't use sleep(1) I get a race condition and it runs "forever" (I stopped waiting after 30s).

I will update my ScaleMM soon, first I want to test Fast Code Benchmark (much slower at startup than Fastmm -> never mind seems due to copyfile of exe).
Btw: I use the FMemoryArray now as a cache with an increment of the offset instead of multiply (add is faster than multiply?)

I have committed version 1.1 with some improvements/optimizations:

Still, the "Fast Code MM Benchmark" results are not good enough:
----------------------------------------------------------------
Average Total Performance: (Scaled so that the winner = 100%)
  D2010       :  100,0
  ScaleMem    :   84,3
Average Speed Performance: (Scaled so that the winner = 100%)
  D2010       :   84,1
  ScaleMem    :  100,0
Average Memory Performance: (Scaled so that the winner = 100%)
  D2010       :  100,0
  ScaleMem    :   50,2
----------------------------------------------------------------

Some tests suffers from many "FreeBlockMemoryToGlobal" and global "GetBlockMemory" calls. So bad combination of
thread memory and FastMM (large) block locking.
Also, large alloc + free + realloc have some lower performance because ScaleMM does a size check first (some extra
overhead) and passes it to FastMM after that.

Note: memory consumption is higher because less optimal memory usage: each thread has its own (partly) used memory.

So these results can be explained (less optimal working because of mixed thread memory + fastmm locking). But in the mean
time this is the best I can get.
Btw: I get much better "StringThreadTest" results if I use ScaleMM on top of HeapMM or VirtualMM (because of no FastMM "large block" locks) but then reallocation tests perform very bad. I hope to fix all these problems with ScaleMM2 (but do not expect results soon).

Yes, it is less relevant.
However, to get a high score (to show ScaleMM is really faster than FastMM) I have to "cheat" my realloc algoritm... :-(
Maybe a simple change of > instead of >= can make a big difference too.

I benchmarked ScaleMM, so it should be "ready for release" now (no crashes in extensive benchmark).
ScaleMM2 is only POC, however a simple app runs fine, but big app won't (mem is never released etc etc).

I changed "the challenge" using pansichar instead of pchar (D2005 was not yet unicode :-) ) and now all tests are running fine.
Hope to post some results soon.

I have some (good) thoughts about how to implement medium blocks in a fast and easy (not complex) way, but need to work (and think) it out first.

Performance with your mods is it a bit faster: 1200ms (my simple demo test) instead of 1300ms.

I found the FastCode MM Challenge this weekend, which contains good MM tests: I already fixed some small problems. Still some AVs wit realloc, hope to fix this soon.

So for large blocks: direct call VirtualAlloc. If we do it with no locks it would scale better than FastMM. Should not be difficult to make.

But what kind of algoritme should be used, or how to buffer/cache large blocks? You don't want to cache blocks of e.g. 10M, and/or reuse it for an alloc of 5M -> too much memory overhead.

Or just no caching: alloc and direct free?