|
PureBytes Links
Trading Reference Links
|
Nice test. That a 16 bit program is faster than a 32 bit program doing the
same thing doesn't make intuitive sense. The assumption here is that all
programs written in 32 bit code are going to be faster than 16 bit code. I
haven't done any work with this type of conversion so I couldn't say for
sure if this is a valid assumption. Still, you would think that even the
worst conversion from 16 to 32 bits shouldn't make the program slower by
200%.
So what else could be slowing it down? Another reason could be that TS is
relying on code written in a different language. VB perhaps? No way! Yes.
Look at the system report screen and tell me that doesn't look and feel like
a VB app. You will notice this more on slower machines where C++ should
still remain snappy while VB drags. Do you think they did all of that math
and graphs and stuff in C++? Doubt it. Maybe they offloaded the
optimization in TS5 to a different company that rewrote it to work with
their code. A pseudo-complied language like VB would run about 3 times
slower than native C++.
What's another reason? We all know that optimization works in the
background in TS4 and should work the same in TS5. This means that a form
of multitasking needs to be implemented. Win 31 doesn't have true
multitasking capability while Win32 does. This probably means that Omega
had to completely rewrite sections of this code. If the multitasking in
Win32 (TS5) is not handled properly or there are more threads other things
in the background in TS5 than in 4, then the system won't run as fast.
What's another reason? Perhaps there's just more data to load in TS5 than
in TS4. Omega probably uses a different mechanism for not only storing but
retrieving data than in TS4. TS5 records seconds, TS4 doesn't. TS5 offers
bid and ask, implied volatility, tick, end of day for a lot of different
type of issues that TS4 doesn't. It seems TS5 makes heavy use of ODBC while
TS4 uses something else (BTRIEVE file?). The process of loading in that
extra data and using ODBC could add a lot of overhead to the TS5
optimization runs that TS4 doesn't have to deal with. TS5 is all COM based
and we don't know how the modules are communicating or how they're threaded.
Perhaps the decrease in performance has to do with making TS5 COM
compatible. Maybe Omega will get around to optimizing this part of TS later
but for now, they've got other bugs to fix. TS5 is more Microsoft compliant
than any other app they've written but that doesn't mean it should run
better.
The point here is that there's a reason why TS5 is slower and it's not nec
because it was poorly implemented in the code. Some of the reasons may be
outside the control of Omega. TS5 is a big program that attempts to be
everything to everybody (aka Win2K). There are a lot of different
technologies being used in TS5 compared to TS4 that aren't readily evident
to the user, not to mention the additional basal overhead (extra data, etc.)
My experience has shown that anybody who knows enough about windows to
program ATL COM knows enough about windows to write solid code. So the idea
that some bonehead programmers wrote ts5 and that's why it's slow doesn't
make sense. Even Microsoft can't write great threaded code using COM. Do a
query in Site Server on say a 1,000 file library and see how that locks the
machine up (450 PII). Omega probably didn't realize that parts of the
program would run as slow as they do but once they built it and realized
oops it doesn't run as fast we thought it would, it was too late. It may be
a windows issue, it may not be.
Take heart though. As machines become faster and faster in the
not-so-distant future, the performance inadequacies of TS5 will fade away.
In the meantime, there's TS4.
B.
> -----Original Message-----
> From: David Elden [mailto:eldenworks@xxxxxxxxxxxxxx]
> Sent: Saturday, July 10, 1999 8:30 AM
> To: Brian Massey; List, Omega
> Subject: RE: Prosuite 2000i problems
>
>
> -----Snip----
> < It does A TON
> of stuff but all the trader sees is a slower system. >
>
>
> For the record, as far as speed is conderned, running optimizations on
> systems for testing
>
> TS2000 no symbols loaded, no symbols being gathered, 1 workspace open, 1
> chart on the workspace, no other running programs, nothing else running in
> the background, no overhead in other words.
>
> running a 2 variable optimization on 10 years of daily data takes about 3
> seconds per optimization
>
> Same setup, same data, same system, same machine (400mhz 128 mb ram )
>
> on Ts4 is less than 1 second per optimzation.
>
> even doing 1 thing and nothing else, TS2000 is slower than Ts4.
>
>
> d
>
>
>
>
>
>
>
>
|