This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Slow performance on samsung S3C6410

Note: This was originally posted on 18th January 2011 at http://forums.arm.com

Hi,

I'am a software developer and I am trying to port our product to new device. This is Windows CE 6 device with S3C6410 (ARM1176JZF-S) CPU.  The problem is that Q-Bench benchmarks show that this is very fast system but after executing our application it is actually very slow.

I have spend a lot of time profiling various parts of our product, but it shows nothing. Finally what I have found out is that the problem is with the huge code amount. Actually our .exe is ~10MB in size. I have made tests in which I have auto generated huge amounts of code (~200,000 lines of c++ code, VS2005 compiled), and now executing this exe (~1.5MB) on this device shows significant slow down, 8 - 10 times comparing it to other devices (with slower CPUs). This auto generated code does nothing with data, it just executes lots of functions which just increment some variables.

My question is what is the source of problem? From What I know this CPU has  16 KiB instruction cache. Can it be somehow badly configured? I actually have no contact with this device manufacturer. I can only give some hints to its reseler to maybe push information further.

some more info:
Q-Bench Pro - shows that Cache Line == 8, while on other devices it is 32
CeGetCacheInfo - gives below results:
dwL1Flags=0
dwL1ICacheSize=16384
dwL1ICacheLineSize=32
dwL1ICacheNumWays=4
dwL1DCacheSize=16384
dwL1DCacheLineSize=32
dwL1DCacheNumWays=4
dwL2Flags=0
dwL2ICacheSize=0
dwL2ICacheLineSize=0
dwL2ICacheNumWays=0
dwL2DCacheSize=0
dwL2DCacheLineSize=0
dwL2DCacheNumWays=0

Thank You for any help
Martin
Parents
  • Note: This was originally posted on 20th January 2011 at http://forums.arm.com

    this is what I was afraid of, reorganizing code to minimize i-cache reloads is not an easy task from the c++ programmer view, one thing that puzzle me is that our application works OK (among many other CPUs) on the following two:

    MTK, ARM1176JZ-S-MT3351
    sirf arm1136jf-s-a-at550

    I made a benchmark comparison of above two CPUs with the problematic one:

       MT3351(wce5) / at550(wce6) / S3C6410(wce6)
    CPU: 241.113Q / 508.559Q / 505.484Q
    Memory: 229.122Q / 605.436Q / 343.842Q
    File I/O: 21.497KQ / 37.940KQ / 2.586KQ
    GDI: 202.291Q / 415.037Q / 288.697Q

    (this are standardized tests made with QBench Pro and their details can be found here [Removed]
    (File I/O measured on SD card)
    (GDI: MT3351 and S3C6410 is 800x480 screen, at550 is 480x272)

    for each of the above CPUs, CeGetCacheInfo returns the same information.

    I really dont see that S3C6410 is more powerfull than the other two ones. When it comes to CPU it is even a little bit worse than at550.
Reply
  • Note: This was originally posted on 20th January 2011 at http://forums.arm.com

    this is what I was afraid of, reorganizing code to minimize i-cache reloads is not an easy task from the c++ programmer view, one thing that puzzle me is that our application works OK (among many other CPUs) on the following two:

    MTK, ARM1176JZ-S-MT3351
    sirf arm1136jf-s-a-at550

    I made a benchmark comparison of above two CPUs with the problematic one:

       MT3351(wce5) / at550(wce6) / S3C6410(wce6)
    CPU: 241.113Q / 508.559Q / 505.484Q
    Memory: 229.122Q / 605.436Q / 343.842Q
    File I/O: 21.497KQ / 37.940KQ / 2.586KQ
    GDI: 202.291Q / 415.037Q / 288.697Q

    (this are standardized tests made with QBench Pro and their details can be found here [Removed]
    (File I/O measured on SD card)
    (GDI: MT3351 and S3C6410 is 800x480 screen, at550 is 480x272)

    for each of the above CPUs, CeGetCacheInfo returns the same information.

    I really dont see that S3C6410 is more powerfull than the other two ones. When it comes to CPU it is even a little bit worse than at550.
Children
No data