Will multi-core support be available in Xbase++ 2 ?

[unixkd]

Called from DEVCON WEST 2012
From: Steffen Pirsig

In this late-night session, Steffen will talk about the vision Alaska Software has for the Xbase++ development platform. Starting with the basic idea that the Polarfox project is going to be much more than "just" a VFP successor, he will outline details about our technical roadmap and position in terms of 64-bit and native Unicode support. Other major topics are Xbase++ as a stored procedure language for the PostgreSQL server, and how Alaska Software intends to pioneer again* in terms of scalability in the multi-core world of tomorrow. In short, Steffen will talk about the long-term direction envisioned for Xbase++ in light of recent and long-term developments in the IT industry.

*Alaska Software pioneered multithreaded application development more than 10 years ago with its intelligent and automated multithreading. Xbase++ applications are multithreaded in various ways. Garbage collection is asynchronous, event management is done in a separate thread to ensure application responsiveness even under heavy workload. All memory variables are automatically serialized if accessed from different threads, methods can be attributed synchronized...

WILL IT BE AVAILABLE WITH XBASE++ 2.0 ?

[Tom]

Xbase++ already supports multicore-environments - you can switch the cpu the application runs on anytime you like. In fact, the app always runs on one cpu at a time.
But. Xbase++-applications are normally designed in a way that would not benefit from running on multiple cpus. The only situation for this are MDI-apps starting several modules in different threads. But they wouldn't benefit from multiple cpus either, since the user works with one interface (module) at a time, no matter how much of them are started. The bottleneck for us are mass storages and network adapters, not the cpu power.

[unixkd]

Yes Tom

This is the current situation. Steffen made the above comments recently and I simply assume that Xbase++ will address the limitations you mentioned, if I get Steffen correct in his statement. Simply put, when will this technology be available ?

[Tom]

when will this technology be available

Artica was scheduled for late 2007. It maybe available in early 2013. Just count for yourself.

Add: I remember I heard Steffen speaking about 64 bit in .. I don't know exactly. Maybe 2004. What he said back then was something like "We only need to set a compiler switch to support 64 bit natively." What we learn: It may take more than eight years to set a switch.

Waiting for stuff promised by Alaska is somehow like christmas. The wishlist maybe long, but what you get from Santa maybe something completely different. Or even nothing.

[unixkd]

I agree with you Tom.

May be Xbase++ underline architecture is a complicated one. You remember SL1.9 is about 4 years old (2008), yet a lot of my colleagues using C#, VB ...NET, PowerBasic etc. are always amazed about the versatility of Xbase++ and I wonder why. Those languages are updated almost every year or less, yet we don't get tangible upgrade in almost 5 years.

[Tom]

Besides the schedule discussion: 64 bit does not mean "twice as good (or fast)". 64 bit has it's advantages when applications need to address more than 4 GB - or calculate big floating point numbers. On the other hand, 64 bit apps tend to become bigger (about 25 to 30 percent) and - believe it or not - slower. Business apps like the ones we all create may not take profit from that.

Edit: Short overview: http://en.wikipedia.org/wiki/64-bit_com ... _vs_64-bit

[skiman]

Artica was scheduled for late 2007. It maybe available in early 2013. Just count for yourself.

On the home page of Alaska, Steffen is already mentioning Q2 2013. So I wouldn't hope for early 2013, maybe Santa 2013... In March during the Devcon in Germany we got a release candidate with expiry date of 1 September 2012. Steffen promised to give it priority, above his Foxpro project.

[Auge_Ohr]

WILL IT BE AVAILABLE WITH XBASE++ 2.0 ?

simple NO ... but as Tom say you can "switch" CPU at "any time".
see c:\ALASKA\XPPW32\Source\samples\solution\smp\smprun.prg.

here my Demo using Thread to "paint" some Fractal ( see RandomInt() )

morecpu1.exe -> just use 1 CPU
morecpu2.exe -> switch CPU for new Fractal
morecpu3.exe -> switch CPU every 1/10sec

if you need more work für your CPU start with Parameter "more"

[unixkd]

Hi Auge_Ohr

Please send me the source code of your sample.

Thanks

Joseph

[Auge_Ohr]

Please send me the source code of your sample.

as i say Code IS c:\ALASKA\XPPW32\Source\samples\solution\smp\smprun.prg