The future of PureBasic...personal opinion...

Ramihyn_ · Post by **Ramihyn_** » Thu Mar 20, 2008 12:08 pm

64bit

At some point yes - x64/64bit should be supported. But i have just done compatibility tests with a small commercial app partly done in PB in 64Bit Vista and it was a joy to work with the app. I havent seen any problem running the 32bit PB app in Vista 64bit and unless you check the task manager, you dont even notice any difference to 64bit apps.

So while 64bit code definitely needs to be supported in the long run, there is no immediate pressure from what i see. At least not for 64Bit vista and thats my main concern regarding 64Bit OS platforms.

Kaeru Gaman · Post by **Kaeru Gaman** » Thu Mar 20, 2008 12:17 pm

@Berikco
sorry, just was a bit talkative last night....

@Ramihyn

the mayor reason for 64bit is the adressrange you gain.
a 32bit app can "only" adress 4GB, no matter what system it is running on.
for the most simple purposes this seems enough, but for a lot of scientific purposes it isn't.

..and also for game industry it's beginning to get interesting to keep more than 4GB of content in the RAM...

the second reason is the increase of precision in standard register operations.

pdwyer · Post by **pdwyer** » Thu Mar 20, 2008 12:31 pm

Berikco wrote:This thread we see every 3 months...its getting boring.
And i think everythingh is already answered...search a bit...

X64: yes http://www.purebasic.fr/english/viewtop ... 554#223554

Dot.net NO, its somewhere in the forum

Open source: write your own and make it open source, you dont even like it yourself if ppl steal your work to sell as there own, and thats what happenend before with the only open source part of PureBasic.

Its nice when the answer coincides with what you want

Post by **Rings** » Thu Mar 20, 2008 12:41 pm

Berikco wrote:Open source: write your own and make it open source, you dont even like it yourself if ppl steal your work to sell as there own, and thats what happenend before with the only open source part of PureBasic.

well, stealing opensource and sell it is like this

Inf0Byt3 · Post by **Inf0Byt3** » Thu Mar 20, 2008 1:02 pm

I wish that really happened. Because of you asswipes and limewire. I'm slowly losing my job. Go to hall all of you pirates out there. What low life cheap ass nerd steals video games? When you go to jail what are you going to say to that Identity theft, grand theft auto, mass killer, rapist, robbing, terrorist?
What you in for fool?!?
"Oh I illegally pirated halo 3."
* you get anal rapped. *

fool

Ramihyn_ · Post by **Ramihyn_** » Thu Mar 20, 2008 1:20 pm

Kaeru Gaman wrote:@Ramihyn

the mayor reason for 64bit is the adressrange you gain.
a 32bit app can "only" adress 4GB, no matter what system it is running on.
for the most simple purposes this seems enough, but for a lot of scientific purposes it isn't.

With PAE support (any CPU > ppro should have it) and multiple tasks, you can adress more then 4GB. Which "scientific" project would consider using purebasic anyway? I mean real scientific projects and not just some student project.

Actually one of the things i had problems with PB regarding memory, was that allocating/using something like a 800MB block made a stable application suddenly very unstable. 2 GIG main memory and it didnt matter if virtual mem was enabled or not - PB just didnt seem to be able to deal with memory blocks of 800-1200 MB.

Kaeru Gaman wrote:..and also for game industry it's beginning to get interesting to keep more than 4GB of content in the RAM...

PB has AFAIK no share among AAA commercial game titles. So i'm not sure if citing the requirements of the next generation top of the line commercial games is relevant - PB would need to get a foot into that market first

(the PureGDK project is IMHO a good step)

Kaeru Gaman wrote:the second reason is the increase of precision in standard register operations.

That is a matter of operands and not binary codesize. PB already has 64bit operands working in 32bit code.

thefool · Post by **thefool** » Thu Mar 20, 2008 1:26 pm

That is a matter of operands and not binary codesize. PB already has 64bit operands working in 32bit code.

Was that a joke? of course it has. But think about it again and read on wiki

anyway when it comes to audio production, one time they will be native 64bit. Currently my main DAW has internal 64bit precision but runs under a 32bit hood. A 64bit processor will be able to process more data in the same time, logically. Its just a matter of time.

pdwyer · Post by **pdwyer** » Thu Mar 20, 2008 1:49 pm

Ramihyn_ wrote:With PAE support (any CPU > ppro should have it) and multiple tasks, you can adress more then 4GB.

This is a gross over simplification. You don't just set the boot.ini to handle PAE and then suddenly all your needs are fulfilled for large memory access.

There's a LOT of gotcha's, not to mention which OS's it will work on and other hardware issues than just having an Intel ppro

Take a look

http://www.microsoft.com/whdc/system/pl ... AEdrv.mspx

The only app I know that supports it is MS SQL server. There are probably some more I suppose.

64bit is a much more sensible way of supporting large memory access.

At work SQL servers are the only 32bit OS's we run and bother to put more than 4gb in them. Nothing else seems to be able to address it. 64bit is the future.

Kaeru Gaman · Post by **Kaeru Gaman** » Thu Mar 20, 2008 1:58 pm

With PAE support (any CPU > ppro should have it) and multiple tasks, you can adress more then 4GB.

and what is the use of it?
when I want to load the complete heightfield data of the earth (the NASA recorded them lately) into memory to let a function run over it completely, what use would it be to have it splitted in e.g. 16 different segments that probably need their own codesegment?
sorry, thats rediculous...
and this is not the only possible use for 64bit.

Which "scientific" project would consider using purebasic anyway?

why not?
well, atm. PB is not ready for such, but do you want it to stay so forever?

Actually one of the things i had problems with PB regarding memory, was that allocating/using something like a 800MB block made a stable application suddenly very unstable. 2 GIG main memory and it didnt matter if virtual mem was enabled or not - PB just didnt seem to be able to deal with memory blocks of 800-1200 MB.

running on a huge OS with a lot of services in the background on only(!) 2GB RAM and then allocating a single 1GB memblock.... and you say it's PB's fault?
did you ever try exactly the same with another programming language?
don't you think the Mem had to be mapped to the virtual mem?
do you think this cost no time?

PB has AFAIK no share among AAA commercial game titles.

same as above: do you want it to stay this way forever?

That is a matter of operands and not binary codesize. PB already has 64bit operands working in 32bit code.

ok, and you read too fast....

the second reason is the increase of precision in standard REGISTER operations.

seen it now?
your sentence is obsolete. I did not talk about any variables or operants, wich are virtual numbers.
I said "registers".

ok, sorry if I sound angry...
you asked "why 64bit" and I told you why, and then you replied "thats no reason"
pfff...

Ramihyn_ · Post by **Ramihyn_** » Thu Mar 20, 2008 2:40 pm

pdwyer wrote:This is a gross over simplification. You don't just set the boot.ini to handle PAE and then suddenly all your needs are fulfilled for large memory access.

There's a LOT of gotcha's, not to mention which OS's it will work on and other hardware issues than just having an Intel ppro

Take a look

http://www.microsoft.com/whdc/system/pl ... AEdrv.mspx

The only app I know that supports it is MS SQL server. There are probably some more I suppose.

64bit is a much more sensible way of supporting large memory access.

At work SQL servers are the only 32bit OS's we run and bother to put more than 4gb in them. Nothing else seems to be able to address it. 64bit is the future.

I know its not very practical for some purposes as it is like using segmentation of memory which can be a real pain to deal with. I was just mentioning that it actually is possible to address more then 4gb in 32bit software using PAE because most people never heard of PAE. I didnt say 64bit isnt the future or anything - my point is that there is no urgent need to make PB 64bit ready.

If we want to be precise, the memory useable by a single task in 32bit windows (or others) is more close to 3.5gb or even lower.

Kaeru Gaman · Post by **Kaeru Gaman** » Thu Mar 20, 2008 2:51 pm

my point is that there is no urgent need to make PB 64bit ready.

well ok... so I probably took you wrong...
I also think there are more urgent tasks to solve..

the memory useable by a single task in 32bit windows (or others) is more close to 3.5gb or even lower.

a 32bit windows can adress only 4GB allover, left for apps are 2GB,
3GB with a special switch on wich cannot be used by all apps.
2GB is the normal maximum, 3GB is absolute deadline on win32bit.

Ramihyn_ · Post by **Ramihyn_** » Thu Mar 20, 2008 3:15 pm

Kaeru Gaman wrote:
With PAE support (any CPU > ppro should have it) and multiple tasks, you can adress more then 4GB.
and what is the use of it?
when I want to load the complete heightfield data of the earth (the NASA recorded them lately) into memory to let a function run over it completely, what use would it be to have it splitted in e.g. 16 different segments that probably need their own codesegment?
sorry, thats rediculous...

I think its rediculous to start a project like "i want to load the complete heightfield data of the earth into memory" and then be surprised if you cant do it with PB

Thats just another example of a problem 64Bit "solves" which affects only a super tiny group of developers.

Kaeru Gaman wrote:
Which "scientific" project would consider using purebasic anyway?
why not?
well, atm. PB is not ready for such, but do you want it to stay so forever?

There are many other more important things to change in PB before trying to appeal to the scientific community.

For example the main problem PB currently has IMHO is that it is simply not competitive (anymore) for creating 3D games or applications. Next would probably be support for some web-based technology or the ability to compile for symbian based cell phones or something comparable.

From my time at the university, i know the scientific community is very reluctant to using new platforms/languages due to the evaluation problems.

Kaeru Gaman wrote:
PB has AFAIK no share among AAA commercial game titles.
same as above: do you want it to stay this way forever?

No i dont want it to stay this way forever, but support for a good 3D SDK/engine/toolchain is way more important then 64Bit code to change this. Just compare how many AAA commercial games require a 64Bit CPU/OS and how many AAA commercial games are done in PB.

Kaeru Gaman wrote:
That is a matter of operands and not binary codesize. PB already has 64bit operands working in 32bit code.
ok, and you read too fast....
the second reason is the increase of precision in standard REGISTER operations.
seen it now?
your sentence is obsolete. I did not talk about any variables or operants, wich are virtual numbers.
I said "registers".

I didnt miss your "registers" comment, i am simply not convinced that it is really relevant for now. Doing 64Bit operations in 32bit registers is a bit slower, but i would think thats not relevant for most applications nowadays written in PB.

Kaeru Gaman wrote:ok, sorry if I sound angry...
you asked "why 64bit" and I told you why, and then you replied "thats no reason"
pfff...

I still say you didnt tell me good reasons. PB can IMHO safely ignore the scientific community, for 3D games its much more important to actually get a foot into the market (updated 3D and library support) and for processing 64Bit operands with 32bit commands/registers this is just giving you a small performance penalty. I doubt there are more then 5 PB applications where this has a practical impact.

I didnt say "64bit is useless" - i said that "the need for native 64Bit code in PB is currently not urgent". Which means i can likely wait for Q1/Q2 2009 without a problem.

Fluid Byte · Post by **Fluid Byte** » Thu Mar 20, 2008 3:23 pm

Can't we just skip all the blah blah and face the facts? How many PB developers are in the urgent need of 64bit support?

Maybe one? None?

The trivial existence of Vista 64bit doesn't count as an argument!

It's nice to have but a lot of time should, respectivley will, pass until this will be a recent issue for Fred. It's just another pointless jammering for a feature like OOP or bullshit like .NET support. People constantly try to turn PureBasic into a mainstream bastard wich combines all the "fancy" features so often praised by beginners.

Ramihyn_ · Post by **Ramihyn_** » Thu Mar 20, 2008 3:31 pm

Fluid Byte wrote:Can't we just skip all the blah blah and face the facts? How many PB developers are in the urgent need of 64bit support? One? None?

The trivial existence of Vista 64bit doesn't count as an argument!

It's nice to have but a lot of time should, respectivley will, pass until this will be a recent issue for Fred.

IMHO the important thing to know is that you can create windows applications for 64Bit Vista with PB and they will run just fine (from all my tests).

This was rather important for me as an important customer of us suddenly switched to 64Bit Vista

Though i have no clue why they did it. I got myself a Vista 64Bit SB version for 58 € from mindfactory to run tests with.

Kaeru Gaman · Post by **Kaeru Gaman** » Thu Mar 20, 2008 3:31 pm

@Ramihyn
I already answered your before post... you made the work in vain.

I'm too lazy now to pick up some trouble I already left behind almost an hour ago...