Login Page - Create Account

Support Board


Date/Time: Tue, 25 Feb 2020 08:18:51 +0000



[User Discussion] - 32 Bit dll's are fine but I'm having real issues with 64 Bit dll's

[2020-02-07 14:37:14]
User92573 - Posts: 121 | Ending Date: 2020-03-12
Dear Support

I've finally moved to the 64 Bit Platform and had thought rightly or wrongly, that the 64 Bit would have a lesser impact on my hardware but this is not the case. After re-compiling using same name dll's - all are found by the chartbooks/study collections - however SC has real issues loading even the 32 charts in the test workbook. The 32 Bit works fine (different folder) but the 64 Bit constently fails to respond (Sierra Chart not responding) while loading and reports much higher memory and CPU useage - which is not what I'd expected.

During the workbook load I have constant white screens, freezes, delays, a peak useage displayed on the system monitor. After sometime - I get the charts ... until that is I try a replay when it all starts over.

Any thoughts?

Many thanks.
[2020-02-07 19:53:00]
Sierra Chart Engineering - Posts: 81442 | Ending Date: 2020-06-09
What are the specifications of the CPU on the system?

You may need to update your hardware. The 32-bit version of Sierra Chart is still maintained for the time being.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-02-07 19:53:14
[2020-02-08 09:08:17]
User92573 - Posts: 121 | Ending Date: 2020-03-12
On this workstation CPU i7 2600K RAM 16GB.
I was wondering whether compiling the X64 DLL's via Visual Studio 2017 had any known issues?
Many thanks.
[2020-02-08 09:50:07]
Sierra Chart Engineering - Posts: 81442 | Ending Date: 2020-06-09
You may want to use a faster CPU.

No known issues compiling with Visual Studio 2017 however it is recommended to use the build functionality within Sierra Chart so optimizations are definitely done.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2020-02-14 01:39:27]
User791263 - Posts: 123 | Ending Date: 2020-02-29
Does 64bit SC take much more resources on load, as post #1 describes?
That won't work for my 2 to 3 times larger Chartbook than poster's. Like his, my 32 bit (V1991) loads and runs fast.

2 years ago you said an I7 was plenty fast.
A lot of us went with SC for:
backwards compatibility, low resources/moderate hardware requirements, stability and leanness /speed.

Are those still priorities? SC seems to be moving away from those (our (user)priorites).
I'm seeing forced updates/recompiles, less backwards compatibility, poster says lost speed, and you say high-end faster hardware needed.
[2020-02-14 04:33:15]
Sierra Chart Engineering - Posts: 81442 | Ending Date: 2020-06-09
backwards compatibility, low resources/moderate hardware requirements, stability and leanness /speed.
This is all absolutely true.

But some older hardware is not going to execute 64-bit code as fast. This is strictly a hardware issue. It has nothing to do with Sierra Chart in the least. Not at all.

You just have to run your own test and see if your custom studies run the same when built for 64-bit architecture. If your CPU runs it more slowly then your hardware is not well optimized for 64-bit programs. This is all.

Our experience is that the 64 build of Sierra Chart is overall faster with memory allocations and releases. We observe no detrimental performance impact. And we are referring to Sierra Chart itself. Not custom studies.

The simple fact is the vast majority of our users are not noticing any detrimental impact from the 64-bit version. This is a fact.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-02-14 04:34:48
[2020-02-14 05:23:38]
Sierra Chart Engineering - Posts: 81442 | Ending Date: 2020-06-09
But one thing we would say with absolute certainty, is most likely we are going to enforce a policy that versions less than a-year-old are going to get locked out. Newer versions are so much better than prior versions, there is no reason to be running an older version. We are not going to get ourselves burdened with unnecessary support.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2020-02-14 22:29:13]
User791263 - Posts: 123 | Ending Date: 2020-02-29
You may also tune 64 bit versions (threads, etc) to be faster over time.
But "backwards compatibility" is not wiping out non-trade 32 bit 2nd instances with short notice-- when a good "reason" for a work-around (being used) was a spreadsheet compatibility failure of upgrade from V1488--
which conversion takes yet months after months to build a simplified Instance 1 to feed V1488 to be converted.

I'm not seeing requests for support on versions over a year; Nobody expects that.

Wouldn't it take a couple of hours to add a "Read Only Client" [no trade] server setting
to make all of us happy, giving users with larger systems as Instance2 a few more months to figure out how to best convert.
A few users could pitch in about $40 each. I would. SC service would look good.
[I suggested this in the "workaround" thread:
https://www.sierrachart.com/SupportBoard.php?PostID=206823#P206823 ]

[Ill not pester you. You know what's do-able and right]
Date Time Of Last Edit: 2020-02-14 23:05:53
[2020-02-14 23:06:54]
Sierra Chart Engineering - Posts: 81442 | Ending Date: 2020-06-09
That already exists. You need to set Global Settings >> Data/Trade Service Settings >> Service to No Service.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-02-14 23:07:12
[2020-02-16 15:50:40]
User92573 - Posts: 121 | Ending Date: 2020-03-12
Dear Support, here is a brief update.

I'm currently running Win7 Pro 64 Bit; 16GB Ram; I7 2600K (old but almost as fast as 8700K in tests and runs SC32 very fast .. until recently)

Same workbook contents but with appropriate DLL's 32/64.
SC 32Bit loads/changes symbol for a line of 8 charts (same studies) in 3 seconds.
SC 64Bit loads/changes symbol for a line of 8 charts (same studies) in 11-13 seconds and is completely unresponsive until load is fully completed.
System resources are only average which is to be expected with Sierra Charts. RAM does not exceed 50% with CPU'S initially jumping to around 90%.
Adding more complex studies results in the resource monitor presenting multiple 'status not responding' messages screen white-outs and system interupts 'deferred'.

I'm struggling to understand why the 64 BIT version is taking so long to load when it should be so much faster?
I have a 9700K 32GB RAM due on Tuesday but I cant see throwing higher spec hardware given the current use of resources should be necessary.

For myself and others who are comitted to Sierra Charts and consider it an excellent platform can you provide any clarity on why this is so?

Many thanks.
[2020-02-16 20:05:39]
Sierra Chart Engineering - Posts: 81442 | Ending Date: 2020-06-09
I'm struggling to understand why the 64 BIT version is taking so long to load when it should be so much faster?
This is going to be a hardware issue. Microsoft and Intel are best able to answer your question. We simply cannot. We do not have the level of insight that they do. This is not within the scope of our support because this does not have to do with Sierra Chart but rather your hardware.

Other than 8 byte addressing with the 64-bit version, the code is completely identical between the 64-bit and 32-bit version.

You are asking a question that we don't know the answer to. Understand that. This is not a Sierra Chart specific issue at all. People need to understand that.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-02-16 20:17:24
[2020-02-16 20:47:30]
Sierra Chart Engineering - Posts: 81442 | Ending Date: 2020-06-09
We ran a test loading a large intraday data file and no studies. This is what we found:

The system was a notebook computer with an Intel core I7-6700 HQ with 16 GB of memory.

The data file is 1.2 GB.

The 64-bit version loaded the file in 1:04 (Minutes:Seconds)
The 32-bit version loaded the file in 1:32 (Minutes:Seconds)

So as you can see the 64-bit version is actually faster. But why is not something we would know. This is going to be something that only the mainboard manufacturer, Intel and Microsoft can best explain. Logically, from our perspective, we would expect there to be some improvement because there is not any compatibility layer between a 32-bit program and the 64-bit operating system. But we would think that would be a very thin layer where needed. And we would also expect more efficient memory address translations because everything is then handled as 64-bit rather than any conversions.

And you should not underestimate the role of the mainboard you are using and the chipset on that mainboard.

And if you have the exact opposite result, that really should tell you something is not right with your hardware and it was never optimized for 64-bit to begin with.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-02-16 20:49:57
[2020-02-17 21:16:34]
User791263 - Posts: 123 | Ending Date: 2020-02-29
In re your "workaround" to run 32-bit V1488 Instance2 in separate folder...My non-trading V1488 Instance2 (I'm stuck on a few months) has worked so well sharing the Instance1 V1991 server Data folder (when V1488 could connect before forcing us to new version).
Above.. you suggest "No Service" setting. That didn't work, probably because all data including ES, MES then comes from SC server instead of Instance2's shared Instance1 data folder?

I read that not sharing Instance1 Data folder may be best due to slight "data sharing" differences between versions. Are those differences mainly in trading/positions functions? What about pure Read-only data feed to non-trade Instance2?
Should I stop Instance1's server setting and stop using Instance1 Data folder?
(ie: Would SC server feed Instance2's own Data folder?)

Should Instanc1 stay set as Server to authorize ES, MES, YM, ND intraday data to Instance2 (set "no service"), or is authorization handled by the Global account-broker info? (data would come from SC servers to Instanc2 Data folder?)

To post a message in this thread, you need to login with your Sierra Chart account:

Login

Login Page - Create Account