porting code from VRTX on 68K to vxWorks on pentium

I have a project which is a port of code from a 68K based VRTX system
to a vxWorks (5.5.1) based penitum system and we are very displeased
with the execution speed.

On the original hardware (68040 @ 25 MHz), the two time critical tasks
take 1.33 and 1.49 mS each to execute. On the new hardware (pentium3
at 1.8 GHz) the same two tasks take 1.40 and 1.54 mS respectively.

The application code is a direct port of the C source code from VRTX on
a 68K to VxWorks on a P3 with the only changes being those required by
the OS differences and a few related to control register bitfields (big
endian vs. little endian).

We expected a speed increase of _at least_ an order of magnitude. I
have gone though the code and verified that there aren't any taskDelay
calls or hardware accesses that would account for this.

Does anyone have any ideas as to why the code on a much faster
processor is running in basically the same timeframe. Better yet,
any ideas how to make it faster?

I have the target shell and wbd tasks included in the build, how much
are they affecting the execution speed of lower priority tasks?

JiMZ

Hi:

How are you doing these timings? Do you have access to Windview - you
could see if the task is blocked on something at some point.

Are these tasks purely computational also. If you have the ability to
do precise timings and the ability to still run on both systems, I
start with something smaller than your full systems and time those.

The spy task may also shed some light on what's going on.

Larry
jimzat wrote:[color=blue]
> I have a project which is a port of code from a 68K based VRTX system
> to a vxWorks (5.5.1) based penitum system and we are very displeased
> with the execution speed.
>
> On the original hardware (68040 @ 25 MHz), the two time critical tasks
> take 1.33 and 1.49 mS each to execute. On the new hardware (pentium3
> at 1.8 GHz) the same two tasks take 1.40 and 1.54 mS respectively.
>
> The application code is a direct port of the C source code from VRTX on
> a 68K to VxWorks on a P3 with the only changes being those required by
> the OS differences and a few related to control register bitfields (big
> endian vs. little endian).
>
> We expected a speed increase of _at least_ an order of magnitude. I
> have gone though the code and verified that there aren't any taskDelay
> calls or hardware accesses that would account for this.
>
> Does anyone have any ideas as to why the code on a much faster
> processor is running in basically the same timeframe. Better yet,
> any ideas how to make it faster?
>
> I have the target shell and wbd tasks included in the build, how much
> are they affecting the execution speed of lower priority tasks?
>
> JiMZ[/color]

LarryC wrote:[color=blue]
> Hi:
>
> How are you doing these timings? Do you have access to Windview - you
> could see if the task is blocked on something at some point.
>
> Are these tasks purely computational also. If you have the ability to
> do precise timings and the ability to still run on both systems, I
> start with something smaller than your full systems and time those.
>
> The spy task may also shed some light on what's going on.[/color]

Hi Larry,

The timings are accomplished by setting analog levels on a D/A board to
10 volts at the top of the task loops and 0 volts at the bottom of the
task loops. The tasks pend on semaphores just before setting the
analog to 10 volts, the semaphores are released by the ISR of a 10 mS
hardware clock. From this configuration, we can see that the tasks run
for less the 2 mS each and sit idle for over 8 mS.

The code is not all purely computational, in order to rule out any
external events or varying logic, I bracketed a function which simply
contains (a lot of) Boolean math, ANDs and ORs, and find that this
function takes around 1.2 mS to execute (on both platforms).

I have not tried WindView yet, but since these are the highest priority
tasks (aside from OS tasks), I doubt that it will show anything. I
_have_ tried spy, but it interferes with my hard real-time
requirements. After shifting spy's priority, it shows that these two
tasks are using around 50% of my CPU, with 36% IDLE.

Hi:

I still think somethings uo with your timings. Top to bottom within
your task, I believe your numbers, but I think something else is going
on to interrupt your task's execution, whether it's another task or
some interrupts.

I'd taskLock and intLock the task at the top and bottom and see what
you get.

The percentages of time you say you are using are pretty high given the
processor speed.

LC
jimzat wrote:[color=blue]
> LarryC wrote:[color=green]
> > Hi:
> >
> > How are you doing these timings? Do you have access to Windview - you
> > could see if the task is blocked on something at some point.
> >
> > Are these tasks purely computational also. If you have the ability to
> > do precise timings and the ability to still run on both systems, I
> > start with something smaller than your full systems and time those.
> >
> > The spy task may also shed some light on what's going on.[/color]
>
> Hi Larry,
>
> The timings are accomplished by setting analog levels on a D/A board to
> 10 volts at the top of the task loops and 0 volts at the bottom of the
> task loops. The tasks pend on semaphores just before setting the
> analog to 10 volts, the semaphores are released by the ISR of a 10 mS
> hardware clock. From this configuration, we can see that the tasks run
> for less the 2 mS each and sit idle for over 8 mS.
>
> The code is not all purely computational, in order to rule out any
> external events or varying logic, I bracketed a function which simply
> contains (a lot of) Boolean math, ANDs and ORs, and find that this
> function takes around 1.2 mS to execute (on both platforms).
>
> I have not tried WindView yet, but since these are the highest priority
> tasks (aside from OS tasks), I doubt that it will show anything. I
> _have_ tried spy, but it interferes with my hard real-time
> requirements. After shifting spy's priority, it shows that these two
> tasks are using around 50% of my CPU, with 36% IDLE.[/color]

LarryC wrote:[color=blue]
> Hi:
>
> I still think somethings uo with your timings. Top to bottom within
> your task, I believe your numbers, but I think something else is going
> on to interrupt your task's execution, whether it's another task or
> some interrupts.
>
> I'd taskLock and intLock the task at the top and bottom and see what
> you get.
>
> The percentages of time you say you are using are pretty high given the
> processor speed.
>
> LC
> jimzat wrote:[color=green]
> > LarryC wrote:[color=darkred]
> > > Hi:
> > >
> > > How are you doing these timings? Do you have access to Windview - you
> > > could see if the task is blocked on something at some point.
> > >
> > > Are these tasks purely computational also. If you have the ability to
> > > do precise timings and the ability to still run on both systems, I
> > > start with something smaller than your full systems and time those.
> > >
> > > The spy task may also shed some light on what's going on.[/color]
> >
> > Hi Larry,
> >
> > The timings are accomplished by setting analog levels on a D/A board to
> > 10 volts at the top of the task loops and 0 volts at the bottom of the
> > task loops. The tasks pend on semaphores just before setting the
> > analog to 10 volts, the semaphores are released by the ISR of a 10 mS
> > hardware clock. From this configuration, we can see that the tasks run
> > for less the 2 mS each and sit idle for over 8 mS.
> >
> > The code is not all purely computational, in order to rule out any
> > external events or varying logic, I bracketed a function which simply
> > contains (a lot of) Boolean math, ANDs and ORs, and find that this
> > function takes around 1.2 mS to execute (on both platforms).
> >
> > I have not tried WindView yet, but since these are the highest priority
> > tasks (aside from OS tasks), I doubt that it will show anything. I
> > _have_ tried spy, but it interferes with my hard real-time
> > requirements. After shifting spy's priority, it shows that these two
> > tasks are using around 50% of my CPU, with 36% IDLE.[/color][/color]

Hi Larry,
Out of curiosity asking ,Will not including taskLock and UNLOCK add up
to more delays in the system in the case described above?

Regards,
s.subbarayan

Measuring the time between when your task starts and ends doesn't
really represent amount of CPU time used in your task, given other
things like interrrupts and other tasks can be running.

Using windview or some taskhook calls to see what's going on might
help.

task and int locking your code should lead to more accurate timings of
what's going on.

lc
ssubbarayan wrote:[color=blue]
> LarryC wrote:[color=green]
> > Hi:
> >
> > I still think somethings uo with your timings. Top to bottom within
> > your task, I believe your numbers, but I think something else is going
> > on to interrupt your task's execution, whether it's another task or
> > some interrupts.
> >
> > I'd taskLock and intLock the task at the top and bottom and see what
> > you get.
> >
> > The percentages of time you say you are using are pretty high given the
> > processor speed.
> >
> > LC
> > jimzat wrote:[color=darkred]
> > > LarryC wrote:
> > > > Hi:
> > > >
> > > > How are you doing these timings? Do you have access to Windview - you
> > > > could see if the task is blocked on something at some point.
> > > >
> > > > Are these tasks purely computational also. If you have the ability to
> > > > do precise timings and the ability to still run on both systems, I
> > > > start with something smaller than your full systems and time those.
> > > >
> > > > The spy task may also shed some light on what's going on.
> > >
> > > Hi Larry,
> > >
> > > The timings are accomplished by setting analog levels on a D/A board to
> > > 10 volts at the top of the task loops and 0 volts at the bottom of the
> > > task loops. The tasks pend on semaphores just before setting the
> > > analog to 10 volts, the semaphores are released by the ISR of a 10 mS
> > > hardware clock. From this configuration, we can see that the tasks run
> > > for less the 2 mS each and sit idle for over 8 mS.
> > >
> > > The code is not all purely computational, in order to rule out any
> > > external events or varying logic, I bracketed a function which simply
> > > contains (a lot of) Boolean math, ANDs and ORs, and find that this
> > > function takes around 1.2 mS to execute (on both platforms).
> > >
> > > I have not tried WindView yet, but since these are the highest priority
> > > tasks (aside from OS tasks), I doubt that it will show anything. I
> > > _have_ tried spy, but it interferes with my hard real-time
> > > requirements. After shifting spy's priority, it shows that these two
> > > tasks are using around 50% of my CPU, with 36% IDLE.[/color][/color]
>
> Hi Larry,
> Out of curiosity asking ,Will not including taskLock and UNLOCK add up
> to more delays in the system in the case described above?
>
> Regards,
> s.subbarayan[/color]

use a high res timer counter (that runs without interrupt) to save
timestamps / high-res tick values at beginning and end of your code.
Also, record intCnt values at beginning and end.

The values should tell you exact elapsed time for the code execution.
And how many interrupts occurred (if any) during execution of the code.

It could also be floating point support code which is triggering
exceptions.

jimzat wrote:[color=blue]
> LarryC wrote:[color=green]
> > Hi:
> >
> > How are you doing these timings? Do you have access to Windview - you
> > could see if the task is blocked on something at some point.
> >
> > Are these tasks purely computational also. If you have the ability to
> > do precise timings and the ability to still run on both systems, I
> > start with something smaller than your full systems and time those.
> >
> > The spy task may also shed some light on what's going on.[/color]
>
> Hi Larry,
>
> The timings are accomplished by setting analog levels on a D/A board to
> 10 volts at the top of the task loops and 0 volts at the bottom of the
> task loops. The tasks pend on semaphores just before setting the
> analog to 10 volts, the semaphores are released by the ISR of a 10 mS
> hardware clock. From this configuration, we can see that the tasks run
> for less the 2 mS each and sit idle for over 8 mS.
>
> The code is not all purely computational, in order to rule out any
> external events or varying logic, I bracketed a function which simply
> contains (a lot of) Boolean math, ANDs and ORs, and find that this
> function takes around 1.2 mS to execute (on both platforms).
>
> I have not tried WindView yet, but since these are the highest priority
> tasks (aside from OS tasks), I doubt that it will show anything. I
> _have_ tried spy, but it interferes with my hard real-time
> requirements. After shifting spy's priority, it shows that these two
> tasks are using around 50% of my CPU, with 36% IDLE.[/color]

I ran windView and it shows that the two tasks in question run straight
through with only a single clock interrupt (tickAnnounce() call) in
each.

Someone commented that "if the code has lots of ANDs and ORs, maybe
that's creating a lot of branches in the code that defeat the prefetch
and cache." One portion of the code, which is built as an individual
module, is nothing but Boolean math (lots of ANDs and ORs). Does
anyone have any gcc command line switch suggestions?

JiMZ


LarryC wrote:[color=blue]
> Measuring the time between when your task starts and ends doesn't
> really represent amount of CPU time used in your task, given other
> things like interrrupts and other tasks can be running.
>
> Using windview or some taskhook calls to see what's going on might
> help.
>
> task and int locking your code should lead to more accurate timings of
> what's going on.[/color]