Hi,

When I said interpreted I meant in the sense of most "Basics" where there
is a parsing into tokens which are then interpreted at runtime. I do not
know exactly what TradeStation is doing internally, but I do know that the
identical system coded in EL runs anywhere from 20 to 120 times slower
than it does on CT-Pro (compiled C/C++) -- this was certainly the case for
2000i and earlier versions, which I have actually tested, and I have been
told that the newer versions are even slower!

As far as the GA is concerned, the algorithm itself involves relatively
few operations computed on only a small number of values (the parameters).
So, we have a small number of calculations that are coded in
highly-efficient, compiled C; this means really fast execution and minimal
CPU usage. On the other hand, the fitness evaluation, done in EL,
requires large numbers of calculations on long series (arrays) of data and
it is performed in a slow, interpreted environment (20-120x slower than
the same calculations in C). This means relatively s-l-o-w computation of
the fitness at each step of the evolutionary process.

Again, I will stand by what I had said: the GA (coded in C in a simple
DLL) probably accounts for less than .05 percent of the CPU time, with the
rest being eaten by the EL fitness calculation code. Also, if TS uses
Active-X, it could be incredibly slow-- just think of Excel and its VBA (I
have used Excel 97 and 2000) which runs thousands of times slower than,
say, Octave (the GNU matlab clone), and can bring even the fastest
machine to an absolute crawl!.

Hope this clarifies the issues.

Jeff


On Tue, 2 Jun 2009, jhess314 wrote:

> --- In scientific-traders@yahoogroups.com, Jeffrey Owen Katz <jeffkatz@...>
wrote:
>>
>> ... is being run in TradeStation's very slow, interpreted
>> (rather than compiled) Easy Language.
>>
>> Jeff
>>
>
>
> Without arguing whether TradeStation is fast or slow, I would offer the below
comments from the TradeStation forum:
> John
>
> ^^^^^^^^^^^^^^^^^^^^^^^
>
> 04/22/2004
> [comments by a TradeStation engineer]
>
>>> Is EasyLanguage interpreted?
>
> EasyLanguage is a compiled language... The "verification" process is the
compilation process that generates the object code.
>
>
>>> Does an external DLL call take up more time and resources
>>> than an EasyLanguage function call?
>
> This would be subject to test on a case-by-case basis... In general, we
recommend the use of EasyLanguage whenever possible...
>
> One additional key point is that the EasyLanguage Extension SDK does provide
access to price data, so this data need not be passed to a DLL. More detail on
this can be found in the documentation of the EasyLanguage Extension SDK, which
is available through the Help menu, and also here:
>
>
http://www.tradestationsupport.com/resources/07_01/userguide/download/EasyLangua\
ge_Extension_SDK.pdf
>
>
> Kindest regards,
> John Bruch, EasyLanguage Engineer
> TradeStation Securities, Inc.
> Have you tried the EasyLanguage FAQ?
> Your question may already be answered!
>
> ^^^^^^^^^^^^^^^^^^^^^^^
>
> 06/17/2007
> [comments by a TradeStation user]
>
> EasyLanguage is compiled into tokens (where one token is an EasyLanguage
keyword like "buy", a variable reference like "Length", a constant like "3.0",
an operator like "/", etc.). This happens when you "verify" your strategy. It is
compiled, in that some of the work is done before the strategy or analysis
technique is run for each tick or bar. It is not, however, compiled in the
unqualified sense that an unmanaged .EXE is compiled, in that the compilation
does not result in executable code that can run without being further
interpreted directly on Intel-compatible hardware and a Windows-compatible
operating system.
>
> The compiled tokens are then interpreted at run-time on the chart or
RadarScreen. The run-time interpreter does not need to figure out which keyword
synonym you used, or to do things like look for skip words because this work has
already been done - the interpreter is the equivalent of a state machine which
executes the tokens generated by the compilation process, updating the latest
values of varies, and so forth and moving to the next "instruction".
>
> So both views are correct - it is compiled into object code as John stated,
and it is then executed ("interpreted"), but not directly by an Intel-compatible
processor - rather, by the TradeStation platform application.
>
> …
>
> My comments are based simply on observation, after years of experience working
with interpreted token-based languages (such as most but not all BASICs are) as
well as pre-compiled languages (such as C++). I do not "know" the above in the
sense that I did not reverse-engineer the TradeStation platform to determine it
with certainty, but I believe it's fairly obvious that what I said is correct.
>
> I want to be clear that I am not saying EasyLanguage is interpreted in the
same sense that, say, a scripting language (like DelphiScript) or an MS-DOS
batch file is interpreted - those languages are not reduced to tokens in a
compilation phase separated from execution in the way EasyLanguage is, and this
is one reason there is not a big startup delay when you apply a complex
EasyLanguage indicator to a chart - some of the work has already been done when
you verify the raw source code and that is what I am referring to as
"compilation" above.
>
> EasyLanguage provides some of the benefits of both compilation and
interpretation approaches, and is a balanced solution to a complex problem.
>
> ^^^^^^^^^^^^^^^^^^^^^^^
>
> 05/28/2005
> [comments by a TradeStation user]
>
> EasyLanguage is compiled, not interpreted, FYI, EquityBoost.
>
> While C+ and C# do handle arrays more efficiently than EasyLanguage and
VisualBasic (which EL is very similar to) do, even in C+ and C#, arrays cannot
escape the base underlying logic and number of instructions executed, that
inescapably must be executed, to initialize and to then step through, an array.
Only specialized hardware can overcome that.
>
> …
>
> I don't know what EL compiles into, if not into Pentium//AMD machine level
code. You would have to ask TS developers that.
>
> Performance problems in large part are caused by anything that must be carried
for each bar on a chart. An array is replicated by however many bars of history
are used. That eats up incredible amounts of memory.
>
> New 8.1 features added significantly to the data that is carried for each bar,
causing use of more memory, throwing most PCs with under 4 GB (and those at 4
GB) DDR memory into significant paging, which really kills performance.
>
> Regardless of what TS is compiled into, arrays are performance killers, its
the nature of TS architecture, being a bar by bar, tick by tick, real time
architecture.
>
> Does TS use the most current Windows and .net functions to improve
performance? My guess is, no - TS was essentially architected and developed long
before .net and XP and the ersatz so-called 64 bit AMD processors and P4's and
all of their now available registers, caches, expanded instruction sets, and
related chip sets.
>
> Rearchitecting TS - which might now be required - is a high risk, extremely
expensive, l-o-n-g project, even if largely outsourced to cheaper IT labor in
Brazil, Russia, Latvia, China or India. By which time, true 64 bit processors
and their chip sets, and Longhorn may finally be out, rendering the redo of TS
architecture obsolete again.
>
> Likely quite a quandry internally at TS, I guess. It may be so large as to
pose a bankruptcy risk, if tackled too quickly rather than in pieces - but I
have no inside info about that, of course, nor of the internal architecture of
TS 8.1.
>
>
>
>