Teaser for the upcoming release
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
Teaser for the upcoming release
Stock up on RAM and achieve what’s never been possible with EasyLanguage! See attached image.
- Attachments
-
- MCx64.PNG
- (226.2 KiB) Downloaded 4983 times
- TJ
- Posts: 7743
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2223 times
Re: Teaser for the upcoming release
64 mil ticks !!!Stock up on RAM and achieve what’s never been possible with EasyLanguage! See attached image.
I think I will need a faster computer... and a SSD to go with it.
-
- Posts: 742
- Joined: 09 Apr 2010
- Location: Texas
- Has thanked: 483 times
- Been thanked: 274 times
- Contact:
Re: Teaser for the upcoming release
How long did it take to load the 1 tick bars ? (from 2003 to 2011)
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
Re: Teaser for the upcoming release
It took less than 5 minutes in debug mode on a modest pc so it is more than expectable for such an advanced analysis.
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
- furytrader
- Posts: 354
- Joined: 30 Jul 2010
- Location: Chicago, IL
- Has thanked: 155 times
- Been thanked: 217 times
-
- Posts: 742
- Joined: 09 Apr 2010
- Location: Texas
- Has thanked: 483 times
- Been thanked: 274 times
- Contact:
Re: Teaser for the upcoming release
My only concern is the 32bit dll's that I call from the PE for Jurik, Neural Net, etc.
I wish there were some sort of "compatibility mode" for calling 32bit dll's..
I wish there were some sort of "compatibility mode" for calling 32bit dll's..
-
- Posts: 62
- Joined: 03 Nov 2011
- Has thanked: 12 times
- Been thanked: 2 times
- furytrader
- Posts: 354
- Joined: 30 Jul 2010
- Location: Chicago, IL
- Has thanked: 155 times
- Been thanked: 217 times
Re: Teaser for the upcoming release
By looking at the screen shot I estimate as follows: About 5.2 gig of virtual memory being used for the entire program. I'm not familiar with the SysInternals tools, but it appears that all the programs running are using in excess of 94% of physical memory, so I'm guessing that the machine has 4 gig of RAM and the rest of the program is via the hard disk swap area.To load 64 million ticks, how much RAM did you need?
Andrew said it was running on a "modest" PC and took ~5 minutes to load.. So I assume a 64 bit operating system, with 4G of RAM. A slightly more robust machine with 8G of RAM would be much faster as there would be no disk swapping taking place, just loading from the database into RAM memory.
Jack
Re: Teaser for the upcoming release
This is more than adequate. However.It took less than 5 minutes in debug mode on a modest pc so it is more than expectable for such an advanced analysis.
Firstly, since we'll have the opportunity to work with tick data spanning several years, would it be possible to noticeably speed up ASCII import/mapping operations? I imagine, import of a couple of 5-6 Gb tick data ASCII files will take ages. Or maybe a PC upgrade could help with this?
And secondly, would it be possible to increase tick-by-tick replay speed by the time x64 version comes out to 1k (10k-100k) ticks per sec.?
Re: Teaser for the upcoming release
64 bit is great but...
Are you leaving users who are (for many reasons..) required to use
- XP Windows
- 32 bit DLLs that cannot be upgraded to 64bit
behind?
What are our options? Just stick to the last 32 bit version and never upgrade? I hope this is the not the case. Thanks!
mno
Are you leaving users who are (for many reasons..) required to use
- XP Windows
- 32 bit DLLs that cannot be upgraded to 64bit
behind?
What are our options? Just stick to the last 32 bit version and never upgrade? I hope this is the not the case. Thanks!
mno
Re: Teaser for the upcoming release
The computer with 32-bit OS you currently use will become obsolete latest in a year or two. So you can easily subsitute the word ''never'' with ''max 2 years''.What are our options? Just stick to the last 32 bit version and never upgrade?
I am not sure how MC team is going to handle this, but I think that once the benefits of having an MC 64-bit version are proven, you will want to throw your 32-bit machine out of the window and rush to a computer store for a new 64-bit rig.
Re: Teaser for the upcoming release
I guess my plan to upgrade my machine to another 32 bit machine is now delayed even farther and I will make the 2 to 3 monitor upgrade with the current machine instead. Saves me some money for sure. So it sounds like 32 bit machine sales will slump soon. What about 128 bit? When is that coming How about the nano revolution and the nano computer? See the link below.The computer with 32-bit OS you currently use will become obsolete latest in a year or two. So you can easily subsitute the word ''never'' with ''max 2 years''.
I am not sure how MC team is going to handle this, but I think that once the benefits of having an MC 64-bit version are proven, you will want to throw your 32-bit machine out of the window and rush to a computer store for a new 64-bit rig.
The nature of things "The nano revolution - Welcome to nano city" can be found at this link.
http://www.cbc.ca/documentaries/natureo ... video.html
Since the Nano Revolution is already under way, it sounds like the Nano computers may just come before the 128 bit old technology and maybe jump directly to 1024 bit. Maybe by that time programs will be able to out do humans at pattern recognition and we can just buy a computer and MC and get rich However as much fun as it is to dream, probably not. I am sure the Market makers will figure something out to prevent that while at the same time keeping all those commissions coming in
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
Re: Teaser for the upcoming release
About 5Gb.To load 64 million ticks, how much RAM did you need?
It couldn't be improved significantly. We suggest you to use the ASCII Import.Firstly, since we'll have the opportunity to work with tick data spanning several years, would it be possible to noticeably speed up ASCII import/mapping operations? I imagine, import of a couple of 5-6 Gb tick data ASCII files will take ages. Or maybe a PC upgrade could help with this?
Yes it will be improved.And secondly, would it be possible to increase tick-by-tick replay speed by the time x64 version comes out to 1k (10k-100k) ticks per sec.?
The 32bit dlls will not work because it is not possible theoretically. Some open source DLLs like ADE o GlobalVariable will be converted by us.I wish there were some sort of "compatibility mode" for calling 32bit dll's..
No, we will support 32 and 64 bit versions.Are you leaving users who are (for many reasons..) required to use XP?
Re: Teaser for the upcoming release
Hi,My only concern is the 32bit dll's that I call from the PE for Jurik, Neural Net, etc.
I wish there were some sort of "compatibility mode" for calling 32bit dll's..
This is Fantastic !!!!!!!!!!!!! This is really christmas , I can not believe it !!!!
TSSUPPORT Team, you are fantastic !!!!!!!!!!!!
I have the same concern, I am using 32 bit Dll as well. I hope we will have some solution for it.
I am a developper, I had the same challenge few years ago (arround 1991), when we was all using 16 bits Dll/software and we all had to use 32 bits software/system.
We had to find solution to using 16 bit DLL, with 32 bits softwares. And we have to find a solution as well now because most of the DLL are 32 bits, And we all have need for it. It will make the transition smoother, and more people will able to upgrade faster to the 64 bits version.
We had a process call "Thunking process", I developped, 32 bit dll, which was the bridge between, 32 bit applications and 16 bits Dll.
It was not too difficult. I think it is possible to develop 64 dll which translate, (32 bit long into 64 bit long for example etc...)
I think it is possible for Powerlanguage to read 32 bit dll as well. the only difference is when it read the variable,
for example :32 bit dll long for example, it have to make the difference between the long variable dll 32 bits and the long variable dll 64 bits. because the size of the integer is larger.
The only difference is when we send the variable. The only difference it the size of the variable that's all. The process is the same behind it the function.
I think this option is necessary when we see the number of DLL 32 bits we are using.
Most of the indicator, signal provider arround powerlanguage are 32 bits. and every user of Multicharts need 64 bits because it is the main software and we need to be able all the memory available in the computer.
TSSUPPORT team can not developp two version very long, it will double all the developpement job to keep 32 bits versions.
It is better to implement from the beginning, the possiblity to read from the powerlanguage 32 and 64 bit dll. It is will be more efficient for the developpement of Multicharts, all the customer will be able to upgrade faster to the 64 bit Multicharts.
And every body have 32 bits dll indicators that we use and test sooner or later, if they are not already using some DLL 32 bits.
I think we have real need for it as customer user, Multicharts TSSUPPORT need to anticipate this need, if they don't want to double they job maintaining a 32 bits version.
Conclusion, every body need to be able to read 32 bits and 64 bits dll , to have faster migration to Multicharts 64 bits, and to have a faster developpement of Multicharts.
Emmanuel
Re: Teaser for the upcoming release
It's great that everyone is getting excited about the 64 bit version but unfortunately I have more concerns than excitement and I think I am not the alone one..
I run multiple MCs on multiple servers and I use customized GVs, DLLs, etc, etc. that are all 32 bit mode. Yikes, I even have TS2000i Globalserver, etc still on them and require Globalserver to feed me the data.. Some I can update but some there is no way for me to get it upto 64 bit mode.
So for me, it's not just matter of reformatting windows to Win7 or therof in 64 bit and installing MC's new upcoming 64 bit version. Since other required modules won't work, I would not be able to trade anymore hence my serious concern.
I am hoping know MC's long term plans of updating both versions. If only in 64 in the near future, I'm in trouble...
Thanks.
mno
I run multiple MCs on multiple servers and I use customized GVs, DLLs, etc, etc. that are all 32 bit mode. Yikes, I even have TS2000i Globalserver, etc still on them and require Globalserver to feed me the data.. Some I can update but some there is no way for me to get it upto 64 bit mode.
So for me, it's not just matter of reformatting windows to Win7 or therof in 64 bit and installing MC's new upcoming 64 bit version. Since other required modules won't work, I would not be able to trade anymore hence my serious concern.
I am hoping know MC's long term plans of updating both versions. If only in 64 in the near future, I'm in trouble...
Thanks.
mno
- furytrader
- Posts: 354
- Joined: 30 Jul 2010
- Location: Chicago, IL
- Has thanked: 155 times
- Been thanked: 217 times
Re: Teaser for the upcoming release
To quote above:
Are you leaving users who are (for many reasons..) required to use XP?
No, we will support 32 and 64 bit versions.
Re: Teaser for the upcoming release
Hi
I agree with mno, I am using 32 DLLs for years, and there is no way for me to get 64 bits
because no 64 bit upgrade won't be available.
That is why we need to have a way read 32 bit and 64 bit dll. Otherwise we will loose many indicators , we will loose many signal and strategy
I think it is possible :
Accessing 32-bit DLLs from 64-bit code
http://blog.mattmags.com/2007/06/30/acc ... -bit-code/
Emmanuel
http://www.viva64.com/en/l/0002/#ID0ELGAC
http://blogs.msdn.com/b/oldnewthing/arc ... 06720.aspx
I agree with mno, I am using 32 DLLs for years, and there is no way for me to get 64 bits
because no 64 bit upgrade won't be available.
That is why we need to have a way read 32 bit and 64 bit dll. Otherwise we will loose many indicators , we will loose many signal and strategy
I think it is possible :
Accessing 32-bit DLLs from 64-bit code
http://blog.mattmags.com/2007/06/30/acc ... -bit-code/
Emmanuel
http://www.viva64.com/en/l/0002/#ID0ELGAC
http://blogs.msdn.com/b/oldnewthing/arc ... 06720.aspx
Last edited by Emmanuel on 13 Dec 2011, edited 1 time in total.
- TJ
- Posts: 7743
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2223 times
Re: Teaser for the upcoming release
It's great that everyone is getting excited about the 64 bit version but unfortunately I have more concerns than excitement and I think I am not the alone one..
I run multiple MCs on multiple servers and I use customized GVs, DLLs, etc, etc. that are all 32 bit mode. Yikes, I even have TS2000i Globalserver, etc still on them and require Globalserver to feed me the data.. Some I can update but some there is no way for me to get it upto 64 bit mode.
So for me, it's not just matter of reformatting windows to Win7 or therof in 64 bit and installing MC's new upcoming 64 bit version. Since other required modules won't work, I would not be able to trade anymore hence my serious concern.
I am hoping know MC's long term plans of updating both versions. If only in 64 in the near future, I'm in trouble...
Thanks.
mno
Hi
I agree with mno, I am using 32 DLLs for years, and there is no way for me to get 64 bits
because no 64 bit upgrade won't be available.
That is why we need to have a way read 32 bit and 64 bit dll. Otherwise we will loose many indicators , we will loose many signal and strategy
Emmanuel
Please read post #18
...
The 32bit dlls will not work because it is not possible theoretically. Some open source DLLs like ADE o GlobalVariable will be converted by us.I wish there were some sort of "compatibility mode" for calling 32bit dll's..
No, we will support 32 and 64 bit versions.Are you leaving users who are (for many reasons..) required to use XP?
Re: Teaser for the upcoming release
Hi
Thank you TJ for your answer.
1/ I disagree , it is possible to for a 64 bits application to read 32 bits dll :
http://blog.mattmags.com/2007/06/30/acc ... -bit-code/
2/ Global variable is slower, and won't solve the problem, it won't establish a connection between MC 64 bits and the 32 DLL, will it ?
Best Regards,
Emmanuel
Thank you TJ for your answer.
1/ I disagree , it is possible to for a 64 bits application to read 32 bits dll :
http://blog.mattmags.com/2007/06/30/acc ... -bit-code/
2/ Global variable is slower, and won't solve the problem, it won't establish a connection between MC 64 bits and the 32 DLL, will it ?
Best Regards,
Emmanuel
Re: Teaser for the upcoming release
It seems, the best solution is to have a choice of both x86 and x64 versions. Which is exactly what we'll be provided with.
I don't think it's humanly possible to develop a universal x64->x86 wrapper, which will let each and every one 5+-year old x86 .dll work flawlessly with the x64 version of MC.
I don't think it's humanly possible to develop a universal x64->x86 wrapper, which will let each and every one 5+-year old x86 .dll work flawlessly with the x64 version of MC.
Re: Teaser for the upcoming release
Hi Txls,
I agree, it is probably the best solution to have the 32 bits and 64 bits.
TSSupport are doing their best , we know it, their job are excellent.
As long as we have the 32 bits version, we can use the 32 bits dll.
And we can use the 64 bits version for the newer job.
Emmanuel
I agree, it is probably the best solution to have the 32 bits and 64 bits.
TSSupport are doing their best , we know it, their job are excellent.
As long as we have the 32 bits version, we can use the 32 bits dll.
And we can use the 64 bits version for the newer job.
Emmanuel
- Dave Masalov
- Posts: 1712
- Joined: 16 Apr 2010
- Has thanked: 51 times
- Been thanked: 489 times
Re: Teaser for the upcoming release
Dear Users,
Again, I would like to point out that we will support both 32 and 64 bits versions of MultiCharts. As for 32 bit external dll functions, they should be used with 32 bit version of MC. This is the operation system limitation. If you want to use your external functions in 64 bit version of MC they should be 64 bit.
All possible solutions to use 32 bit dlls in a 64 bit application, including the solutions described above are based on using an extra 32 bit process and have two major weaknesses:
1. They are limited to one particular dll function and are not universal solutions.
2. They will slow down the performance of your 32 bit dll in 64 bit MC considerably (up to 10 times) compared to 32 bit MC because of the extra processes used.
Again, I would like to point out that we will support both 32 and 64 bits versions of MultiCharts. As for 32 bit external dll functions, they should be used with 32 bit version of MC. This is the operation system limitation. If you want to use your external functions in 64 bit version of MC they should be 64 bit.
All possible solutions to use 32 bit dlls in a 64 bit application, including the solutions described above are based on using an extra 32 bit process and have two major weaknesses:
1. They are limited to one particular dll function and are not universal solutions.
2. They will slow down the performance of your 32 bit dll in 64 bit MC considerably (up to 10 times) compared to 32 bit MC because of the extra processes used.
Re: Teaser for the upcoming release
Hi,
Thank you Dave for your answer,
We understand, we are grateful to have the 32 bits and 64 bits.
With both version we will be able to use the 32 bits DLL and to develop the new 64 bits dll with the new version.
Regards,
Emmanuel
Thank you Dave for your answer,
We understand, we are grateful to have the 32 bits and 64 bits.
With both version we will be able to use the 32 bits DLL and to develop the new 64 bits dll with the new version.
Regards,
Emmanuel
Re: Teaser for the upcoming release
Thank you everyone for your thoughts. I appreciate them and am very relieved that MC will cover both 32 and 64 bits in the future. Through these discussions, I now understand that I should:
1. Stay with 32-bits O/S, MC-32, 32-bit DLLs, etc. and keep enjoying MC's upgrade w/o much worry in the future.
2. If want to go 64-bits then make sure that all my DLL's are true 64-bits and don't bother using wrappers to make it run since it will just slow me down w/o any adavantages going MC-64 since the DLL's will negate the positives.
Hope I am on the right page.
mno
1. Stay with 32-bits O/S, MC-32, 32-bit DLLs, etc. and keep enjoying MC's upgrade w/o much worry in the future.
2. If want to go 64-bits then make sure that all my DLL's are true 64-bits and don't bother using wrappers to make it run since it will just slow me down w/o any adavantages going MC-64 since the DLL's will negate the positives.
Hope I am on the right page.
mno
- JoshM
- Posts: 2195
- Joined: 20 May 2011
- Location: The Netherlands
- Has thanked: 1544 times
- Been thanked: 1565 times
- Contact:
Re: Teaser for the upcoming release
That's impressive, but I'm wondering, will MultiCharts also become (more) hyperthreaded with the new 64 bit version?Stock up on RAM and achieve what’s never been possible with EasyLanguage!
I'm asking because for example strategy calculations and Portfolio Backtester backtests are done with one core, and though it's impressive to be able to load 64 million ticks, if applying a strategy to that data still uses one core, it's going to take a lot of time (or am I mistaken here?).
Regards,
Josh
- TJ
- Posts: 7743
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2223 times
Re: Teaser for the upcoming release
on sequential-specific calculations, only one core can be used.That's impressive, but I'm wondering, will MultiCharts also become (more) hyperthreaded with the new 64 bit version?Stock up on RAM and achieve what’s never been possible with EasyLanguage!
I'm asking because for example strategy calculations and Portfolio Backtester backtests are done with one core, and though it's impressive to be able to load 64 million ticks, if applying a strategy to that data still uses one core, it's going to take a lot of time (or am I mistaken here?).
Regards,
Josh
eg. you cannot liquidate before a position has taken place,
or calculate a consolidated portfolio balance before all the positions are confirmed.
Multi-core/thread, though powerful, cannot speed up calculations that are limited by the above sequences.
Multi-core/thread are best used in multi-tasking.
e.g.
each chart is a task... if you have many charts, multi-core/thread can spread the work load by letting each core/thread handle separate charts.
however if you have only one chart, even if you have many indicators/strategies on it, you will see that only one core is used.
Re: Teaser for the upcoming release
Hi
I can not wait !!!!! I want to test the 64 bits MC !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Please hurry up !!!!
TSSupport team , you are awesome !!!!!!!!!!!!!!!!!!!!!!!!!!!
This is christmas
Emmanuel
I can not wait !!!!! I want to test the 64 bits MC !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Please hurry up !!!!
TSSupport team , you are awesome !!!!!!!!!!!!!!!!!!!!!!!!!!!
This is christmas
Emmanuel
- JoshM
- Posts: 2195
- Joined: 20 May 2011
- Location: The Netherlands
- Has thanked: 1544 times
- Been thanked: 1565 times
- Contact:
Re: Teaser for the upcoming release
I didn't realize that. Thanks for your clear explanation TJ, it seems quite obvious now.on sequential-specific calculations, only one core can be used.
eg. you cannot liquidate before a position has taken place,
or calculate a consolidated portfolio balance before all the positions are confirmed.
Multi-core/thread, though powerful, cannot speed up calculations that are limited by the above sequences.
Regards,
Josh
- Stan Bokov
- Posts: 963
- Joined: 18 Dec 2009
- Has thanked: 367 times
- Been thanked: 302 times
Re: Teaser for the upcoming release
Thank you everyone for your thoughts. I appreciate them and am very relieved that MC will cover both 32 and 64 bits in the future. Through these discussions, I now understand that I should:
1. Stay with 32-bits O/S, MC-32, 32-bit DLLs, etc. and keep enjoying MC's upgrade w/o much worry in the future.
2. If want to go 64-bits then make sure that all my DLL's are true 64-bits and don't bother using wrappers to make it run since it will just slow me down w/o any adavantages going MC-64 since the DLL's will negate the positives.
Hope I am on the right page.
mno
That's correct.
-
- Posts: 742
- Joined: 09 Apr 2010
- Location: Texas
- Has thanked: 483 times
- Been thanked: 274 times
- Contact:
Re: Teaser for the upcoming release
Question: Will we be able to install BOTH 32 bit and 64 bit versions of MC on the same computer ?? (so for example, we could use 32 bit ver for trading and 64 bit ver for testing ? - not at the same time though)
Re: Teaser for the upcoming release
Excellent point. It's actually mandatory otherwise a lot of us who have developed custom DLLs and the like might find some nasty surprises that will need fixing, and this will take time. This also opens an old can of worms. For the transition to be smooth as possible for all traders, we should be able to run both versions at the same time on different computers. It would suffice to restrict only one of them to be on-line to allow us to trade with the 32-bit version while we test and modify our custom work with the off-line one.Question: Will we be able to install BOTH 32 bit and 64 bit versions of MC on the same computer ?? (so for example, we could use 32 bit ver for trading and 64 bit ver for testing ? - not at the same time though)