Set CPU

[Tom]

In addition: Having more and more Terminal Server Topologies running out there ("cloud"), it end's up with using a single core is not such a bad idea at the end.
We offer our customers various processor selection strategies (random, balanced, prioritized), and since the application is mostly just waiting for user input anyway, this works excellently.

[unixkd]

Hello everyone there.

Are there reasons why Alaska is avoiding multi core support and 64bit application

I am just being curious.

Thanks

Joe

[Tom]

Hi, Joe.

I remember that Alaska explained they don't want to support two different versions. 32 bit is still needed, since lots of ActiveX-controls don't support 64 bit, and there may be still some computers out there with XP or Windows 7 on them. And for a short time, Xbase++ did support multicore situations, but that was a mess (in 1.8 or so).

[unixkd]

Hi Tom

Thanks again for your response. If multi core support truely improve performance then it would have been better for Alaska to fix the problem rather than abandoning it albinitio.

As per 64bit Alaska may need to find a way to accommodate it since it allows applications to access more memory.

Thanks

Joe

[Tom]

As per 64bit Alaska may need to find a way to accommodate it since it allows applications to access more memory.

Which turns into a big problem. Tools like List&Label get better and better - and bigger and bigger. That forced us to play around with the memory usage settings for Xbase++-applications (XPP_CFG_MOM_MEMORYSPACE), which allows to set the memory reserved for the application itself (and the memory left over for tools loaded by the application), but only as a part of the 2 GB it can use at maximum. With every new version of L&L (and other 3rd party products), we start playing again. In an age of infinite memory, this is kind of gross.

[k-insis]

Imho probably lack of will and financial resources to hire people capable to implement multi-core and upgrade compiler and libraries to 64bit.

Hello everyone there.

Are there reasons why Alaska is avoiding multi core support and 64bit application

I am just being curious.

Thanks

Joe

[k-insis]

hi mr Tom

Out of curiosity , how big is memory footprint of L&L for something like general ledger or invoicing report?

Am thinking about finaly going for L&L or biting sour apple and and just offload report generation to app server and use one of open source reporting tools to produce html5/pdf reports.

As per 64bit Alaska may need to find a way to accommodate it since it allows applications to access more memory.

Which turns into a big problem. Tools like List&Label get better and better - and bigger and bigger. That forced us to play around with the memory usage settings for Xbase++-applications (XPP_CFG_MOM_MEMORYSPACE), which allows to set the memory reserved for the application itself (and the memory left over for tools loaded by the application), but only as a part of the 2 GB it can use at maximum. With every new version of L&L (and other 3rd party products), we start playing again. In an age of infinite memory, this is kind of gross.

[Tom]

how big is memory footprint of L&L for something like general ledger or invoicing report?

I can't tell you exactly. The component eating the most resources is the runtime form designer. At least, there should be around 400 MB available for L&L.

[SlavkoDam]

Hi,

Here is a demo program of multi CPU usage. Try it.

[omni]

think I will ask if it can be done a different way. Can you have a differently named app for half the users and somehow assign that app to cpu 1 instead of cpu 0, the default. Or am I just kidding myself.

Fred