Welcome Guest. Please Login or Register. Apr 1st, 2018, 04:03am
ATTENTION MEMBERS: Conforums will be closing it doors and discontinuing its service on April 15, 2018. We apologize Conforums does not have any export functions to migrate data. Ad-Free has been deactivated. Outstanding Ad-Free credits will be reimbursed to respective payment methods.
Thank you Conforums members.
Speed up Liberty BASIC programs by up to ten times!
Compile Liberty BASIC programs to compact, standalone executables!
Overcome many of Liberty BASIC's bugs and limitations!
Re: Open reply to Carl Gundel
« Reply #1 on: Jun 11th, 2017, 06:14am »
Why would anyone need to allocate 1 Gb contiguous memory with LB in the first place?
I think it is absurd. What kind of application will use it?
Maybe, I am old school started with a 16 Kb IBM PC and handled serious banking systems with 1 Mb RAM, can not grasp the need for such memory.
Seriously 70 Mb was enough but say you need to make some image manipulation on RAW image files, maybe increase it to 128 Mb but 1 Gb or more can be needed for video content but why copy all file to memory?
Say you allocated 1 Gb with LB, is it fast enough to handle such huge manipulation with LB?
Why would anyone need to allocate 1 Gb contiguous memory with LB in the first place? I think it is absurd. What kind of application will use it?
I think Carl was just greedy. His lack of understanding of Windows fundamentals led him to conclude that it was OK to allocate that much contiguous memory, and he wanted to use it as a 'headline grabbing' enhancement for LB 4.5 (even if nobody actually needed it). A cynic might suggest he hoped it would distract from all the bugs LB 4.5 doesn't fix.
Quote:
1 Gb or more can be needed for video content but why copy all file to memory?
Absolutely, and in any case even LB 4.04 can if necessary allocate huge amounts of memory using API calls (e.g. GlobalAlloc or MapViewOfFile). Arguably, LB 4.5 allocating 768 Mb or 1 Gb for itself actually makes things worse, because far less memory is now available for those API calls to grab, and a program which (say) relies on mapping a large file into memory may run successfully in LB 4.04 but not in LB 4.5.
Carl should have swallowed his pride, learned the true reason for the allocation failures (rather than trying to blame Microsoft) and reduced it to something like 128 Mbytes in LB 4.5.1.
Logged
