Converting TickZOOM Engine to C++? Support C++,Java,& C#?

[greaterreturn]

Quote from vladisld:

What about other side - I mean the engine calling the custom strategy code which is still written in C# ? Are there any such calls?

Yes the custom code can still be in C# -- no difference. I have figured out how to make it "seamless" so there's no difference in how your strategies, etc will work with the engine itself in C++ instead of C#.

Does that answer your question?

What's your estimation of the performance penalty payed ?

None. It will be even faster that before. The reason is that the calls between C# and C++ are only slowed down by marshaling data heap data. So it should be seamless and fast.

Is it still worth the effort from performance POV ?

What does POV mean?

Sincerely,
Wayne

 

[anonymous]

Quote from greaterreturn:

Sure. I was just thinking that once it's available via Java classes, the engine still needs tick data.

So to run the engine you have to pass one end of a TickQueue object.

The other end (in C#) comes from the TickReader.

So in Java all you'll have is the engine and need to create a TickReader.

But, well, the TickReader is only about 20 lines it just opens the file.

The KEY will be to reimplement the TickImpl object for Java.

Then you can read ticks, pass them to the engine for processing.

You know what? It would damage performace significantly to leave the Tick object marshalled from Java or C#.

I wasn't planning it but I'll have to convert the Tick object and TickReader to c++ also.

That way you pass the TickObject a binary buffer for it to parse into itself.

And it also produces a binary buffer for you to write to a file.

Yes. That will be necessary.

Thanks for making me think about this.

I believe strongly in "design" or thinking it through before coding.

That save oodles of time from re-coding rather than realize later you didn't think of something.

Wayne

If I stick with Metatrader I'll have to figure out a way to get those live ticks into the TickQueue. I'll burn that bridge when I get to it.

I believe that POV == point of view.

- Andrew.

 

[vladisld]

Quote from greaterreturn:

Yes the custom code can still be in C# -- no difference. I have figured out how to make it "seamless" so there's no difference in how your strategies, etc will work with the engine itself in C++ instead of C#.

It will be even faster that before. The reason is that the calls between C# and C++ are only slowed down by marshaling data heap data. So it should be seamless and fast.

So if I understand you right - all the calls from the engine to the custom code are parameterless and all the data access from the custom code to the data structured maintained by the engine ( like tick/bars and others ) are also unsafe.

Quote from greaterreturn:
What does POV mean?

Point of View.

 

[Fractals 'R Us]

Quote from Pippi436:

What i don't like is that your project still takes a different direction every week. If this continues, how could i invest work either for personal purposes or contributing something if i don't know whats the situation a week/month from now when your next idea comes up that turns things around again? You need a plan, and stick to it in my opinion. It just doesn't instill much confidence if the project-leader changes language a few days before wanting to going public. With a tool that doesn't exist yet. To a language you didn't use since 10 years.

I don't want to come across as negative, i still think the basic idea is very good, but i am a bit skeptical about the endless zig-zag. Hopefully i will be surprised in the end tho.

Regrads,
P.

I've seen a lot of projects in 30+ years of work in engineering, a lot of projects. Spending a lot of time in the design phase is much better than jumping in and building something. Once the designing is really done, the building part becomes much easier, it just flows in fact.

 

[Equalizer]

Quote from Fractals 'R Us:

I've seen a lot of projects in 30+ years of work in engineering, a lot of projects. Spending a lot of time in the design phase is much better than jumping in and building something. Once the designing is really done, the building part becomes much easier, it just flows in fact.

I would agree with that - makes perfect sense. However, the OP already agreed with a post of mine in a different thread whereby I warned of the dangers of feature creep and the need to avoid analysis paralysis.

 

[greaterreturn]

Quote from vladisld:

So if I understand you right - all the calls from the engine to the custom code are parameterless ...

Almost. At least in C# (maybe not Java) you can pass a structure by value. So there's no need to "marshall" it to the GC. (Sorry if getting too technical.)

So to be more precise, all the methods from the engine to the custom code are either parameterless like Initialize() or have one parameter.

Here's an example:

The engine will call custom code with (if you implement this method)

IntervalOpen()

This one means the default interval for the specific model. That way you can have EasyLanguage like code which works on any interval you configure.

And the engine also calls (if you implement this method)...

IntervalOpen(Interval interval)

The engine calls this one for every interval that the model requested in the Initialize() method.

So in this version of method you can do this:

if( interval == Intervals.Hour1) {

}

if( interval == Intervals.Second10) {

}

So again, all methods are either parameterless or have one parameter, the interval.

There's also IntervalClose(), StartHistorical() EndHistorical() etc.

Most are just events.

and all the data access from the custom code to the data structured maintained by the engine ( like tick/bars and others ) are also unsafe.

Unsafe, why? They will be available through the COM interface and in this case all the data is returned as ints. So they are based by value on the stack.

That means they are inherently "safe" if you're refering to C# "unsafe" concept or thread safety.

In other words, when you call Data.Hours.Open[5] it will call the Bars object in C++ and return an int which will be on the stack.

The same is true of Data.Hours.Time[5] or Data.Hours.EndTime[5] which return a TimeStamp struct which is only helper struct wrapping a double also on the stack.

Frankly, it will be seamless. So you won't have to worry about safety or threading.

Except, it will be unwise to use any static variable, singletons, etc in your custom code. But I can't think why that would ever be necessary. Member variables work fine.

Wayne

 

[greaterreturn]

Quote from Equalizer:

I would agree with that - makes perfect sense. However, the OP already agreed with a post of mine in a different thread whereby I warned of the dangers of feature creep and the need to avoid analysis paralysis.

Thanks and I do agree. I stopped adding features almost 2 weeks ago and just cleaned up code and renamed stuff to make it more intuitive. I did some more thorough testing also.

Now, converting the engine to C++ won't add any features. For example, I won't add Java support before releasing.

And if you consider converting to C++ a feature creep problem then okay. I'll concede that.

Wayne

 

[greaterreturn]

Quote from anonymous:

If I stick with Metatrader I'll have to figure out a way to get those live ticks into the TickQueue. I'll burn that bridge when I get to it.

I believe that POV == point of view.

- Andrew.

Interesting. Can metatrader call com objects?

Metatrader has an "engine" though for converting ticks to bars so it's unclear what use could come of running the TickZOOM engine in your strategies for MetaTrader. Interesting.

Wayne

 

[greaterreturn]

Quote from TrailingStop3:

Hi Wayne,

Yes I saw you post about SWIG, but to be honest I do not think that it is a good idea to change the programming languages and using only a utility to make this change.

To clarify, this isn't "only a utility" the utility just converts things like C# . to :: -> and . in C++ and it's accurate about 90% of the time.

That little issue could be very time consuming for me as a human to do.

Also, it's converting all properties to getters and setters.

In other words, it's saving an ENORMOUS amount of typing.

But it still forces me to review every line of code, also it throws in TODO comments anywhere it's unsure how to translate, etc.

Point is, it allows me to focus my energy on the parts that truly require human intervention. But eliminate the mindless grunt work.

I would be afraid that I run into much more problems than I have before I go this way.

Well, I respect that. I have often been qualified as "fearless". That has pros and cons, of course.

Nobody would care if TickZOOM is that fast in the first release, but there will be some people are disappointed if you delay the release because of the change in the programming language.

Guess what. The C# project is pristine and untouched throughout. That means I can "pull the plug" on the C++ conversion and release the original C# version if necessary.

Trust me, I won't let this drag on weeks before releasing. I don't want it to become vaporware. I'll fall back on C# in a pinch.

And belief me: C++ is not that simple and will have surely a surprise for you to spend your time with.
Anyway I run into most of these problems myself with my project in the past � but that will not mean that you have to make the same mistakes.

Certainly. That's true. There are always unknowns. So I'm open to pulling the plug.

I wish you the best with TickZOOM. Most of what I read sounds really good � so continue your work! If I would have more time left I would be happy to help. But working all day and after that developing my project need all my time (and the family need their share as well!) ;(

Understood.

 

[greaterreturn]

If you provide me a documented API, I'll use that either from Java (likely) or C++ if I feel like learning that.

I strongly recommend against C++ if you already know Java. I'm very excited personally by having this engine accessible to Java. As that's my preferred language. There's so many gotchas in C++ that can be a BEAR to debug if you don't know what you're doing with serious experience behind you.

Java on the other hand is dream with garbage collection, elimination of the header file morass, etc. etc.

For sure, I'm going to write my personal strategies with Java after I or somebody else makes TickZOOM compatible charts. It should only take a few days to convert the TickzOOM C# Chart to use JFreeChart.

It's "techie stuff" but this is a product geared at techies AFAICT so those of us who are interested in the project will be interested in this sort of information. Actually this is sort of the meat and potatoes of what we need to know.

Well, I certainly want it accessible to techies, that's part of my commitment to open source. But it needs to be accessible to non-techies to survive as a project in the long term.

Sincerely,
Wayne