user space space slower performer than malloc space

[Steve Richter]

code that writes blanks to the bytes of a user space appears to run 60%
slower than the same code that writes blanks to an malloc allocated
space. Any ideas why??

here are my timing results:
clear user space. 16 meg 100 times. Begin 21.09.25 End 21.09.33
Elapsed 7294 milliseconds
clear malloc space. 16 meg 100 times. Begin 21.09.33 End 21.09.37
Elapsed 4755 milliseconds

here is my code that writes blanks to a user space:
char* pSpace ;
memset( &usrspc, ' ', sizeof(usrspc)) ;
memcpy( usrspc.name, "TEST17C", 7 ) ;
memcpy( usrspc.lib, "QTEMP", 5 ) ;
memcpy( replace, "*YES", 4 ) ;
sx = 16000000 ;
pSpace = api_Quscrtus( conNull, usrspc, &sx, replace ) ;

for( Ix = 0 ; Ix < 100 ; ++Ix )
{
memset( pSpace, ' ', 16000000 ) ;
}

similar code that writes blanks to malloc allocated space:
sx = 16000000 ;
pSpace = malloc( sx ) ;

for( nIx = 0 ; nIx < 100 ; ++nIx )
{
memset( pSpace, ' ', 16000000 ) ;
}

[Jonathan Bailey]

Steve Richter wrote:

Did you really only run each test once? If so maybe another job in the
system used more or less cpu time while your job was running?
Maybe since you are creating an object in qtemp the additional overhead
of the object creation is responsible? Try doing both the malloc &
object creation in each program but only clearing one of them. Try
doing a longer test - I dont think a few milliseconds is a very
accurate test. Try running several times for a chance at missing other
system activity. Maybe you can get at the cpu time used instead of
elapsed time?

Jonathan

[Steve Richter]

I am pretty sure the test results are accurate. It is running on a
dedicated system and it confirms the poor performance I was seeing with
code of mine that writes to a user space.

I am assuming what is happening is that changes to malloc space are not
written to disk but changes to usrspc space are. What would work is if
my code could turn this "force to disk setting" on and off, but the
CRTS and MODS instructions dont seem to allow that:

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/rzatk/CRTS.htm

-Steve

[walker.l2]

> I am assuming what is happening is that changes to malloc space are not
> written to disk but changes to usrspc space are. What would work is if
> my code could turn this "force to disk setting" on and off, but the
> CRTS and MODS instructions dont seem to allow that:
>

This is way, way out of my area of expertise, but it looks like the
"Existence attribute" bit on CRTS might do this...

(And I suspect you are right in that malloc is allocating RAM, and
Quscrtus is allocating disk space.)

[Elvis]

Set Access State MI instruction might help, not sure.

http://publib.boulder.ibm.com/iseries/v5r1/ic2924/tstudio/tech_ref/mi/SETACST.htm

Perhaps access state code 40?

[Steve Richter]

Elvis wrote:
> Set Access State MI instruction might help, not sure.
>
> http://publib.boulder.ibm.com/iseries/v5r1/ic2924/tstudio/tech_ref/mi/SETACST.htm
>
> Perhaps access state code 40?

I did not see that instruction, but I dont think it will do what I am
looking for. Set access state looks like it is for moving the object to
and from disk. I want to set the paging properties of the space. When
I get some time I will give it a try.

thanks,

-Steve

[Sebastian Schmidt]

On Sun, Nov 12, 2006 at 05:24:10PM -0800, Steve Richter wrote:
> code that writes blanks to the bytes of a user space appears to run 60%
> slower than the same code that writes blanks to an malloc allocated
> space. Any ideas why??

Not that I would have *any* idea, but:

> here are my timing results:
> clear user space. 16 meg 100 times. Begin 21.09.25 End 21.09.33
> Elapsed 7294 milliseconds

^^^^

> clear malloc space. 16 meg 100 times. Begin 21.09.33 End 21.09.37
> Elapsed 4755 milliseconds

^^^^

You should run test cases *much* longer. This is very inaccurate, even
if you are (as you stated in a later posting) on a dedicated machine.
Try to let them run at least one minute (or longer) and more often than
once to get more accurate results.

Sebastian
--
signature intentionally left blank

[Steve Richter]

Elvis wrote:
> Set Access State MI instruction might help, not sure.
>
> http://publib.boulder.ibm.com/iseries/v5r1/ic2924/tstudio/tech_ref/mi/SETACST.htm
>
> Perhaps access state code 40?

Elvis, you are right! There is a huge performance gain when using
SETACST to pin the user space to main memory. After using access code 3
the usrspc space performs better than malloc space:

quschgus_usrspc_space. 3. Begin 14.55.56 End 14.56.00 Elapsed 4076

memset_usrspc_space_pinned. 50. Begin 14.56.00 End 14.56.02 Elapsed
1862
memset_usrspc_space. 50. Begin 14.56.02 End 14.56.08 Elapsed 5541

memset_malloc_space. 50. Begin 14.56.08 End 14.56.10 Elapsed 2883

memcpy_usrspc_space_pinned. 3. Begin 14.56.12 End 14.56.12 Elapsed 426

memcpy_usrspc_space. 3. Begin 14.56.14 End 14.56.18 Elapsed 4119

memcpy_malloc_space. 3. Begin 14.56.20 End 14.56.22 Elapsed 1545

It takes 3x longer to memset blanks to a 16meg usrspc that has not
gotten the SETACST treatment compared to one that has. memcpy of 16meg
runs 10x faster when SETACST is used.

thank you,

-Steve

[Elvis]

Awesome!