64 bitness

[Richard Gaskin]

Mark Wieder wrote:

> Phil-
>
> Saturday, January 10, 2015, 12:30:41 PM, you wrote:
>
>> Is there any possibility there will be a 64-bit server version of 6.7.2,
>> or is the 64-bitness for building iOS apps only? A 64-bit server version
>> would be wonderful for Dreamhost users like myself (assuming it would
>> run at speeds typical to 6.x, and not at 7.x speeds).
>
> Don't know, but I do note that there are 64-bit servers for the 7.x
> builds. Does that help any?

It gives us half of the solution we need, but unfortunately it's like so 
many other cases in life where half a solution isn't a complete solution.

The remaining issue is performance.

Thanks to Malte's testing initiative, we've identified several areas 
where v7 needs to be optimized to bring it up to performance parity with 
v6.7.  The team is working on that now - kudos to RunRev's recent hire 
Peter B. for his help stewarding the benchmarking effort.

On the desktop the difference is often negligible, but a server 
environment is a harsh mistress where performance is critical and has 
implications for load handling that can impair scalability.

There are two sets of performance issues with LC v7 on a server: runtime 
and startup.

At runtime, we can see in faceless mode pretty much what we can see in a 
GUI, that the wonderful job they've done with Unicode support requires, 
as we expected, more time for encoding checks and coersion.

Additionally, the area we're less likely to care about in a GUI, and 
which matters a lot for any CGI, is startup time.  Peter B. has 
confirmed something I found running LC with strace, that the init 
sequence is spending way too much time on font stuff.

For many versions now we've had the ability to generate graphics from 
the faceless engine, which is nice when you need it but most CGIs don't.

So one option might be to provide a flag for turning off graphics 
handling, and thus bypassing all such initialization with fonts and more 
altogether (hopefully along with removing some of the unused flags that 
are still reserved, as noted in the bug report you filed a while back).

But that would be a last resort.  Right now there's a sense that they 
should be able to speed up init time without having to make us decide 
whether or not our CGI will need graphics support.

So the startup stuff I'm not too worried about, even it is is perhaps 
the largest noticeable difference in overall CGI throughput right now.

Once that's done, it's a far more challenging task to get core 
operations working at 6.7-level speed, things like chunk expressions, 
array split/combine, some aspects of file I/O, and more.

Transparent Unicode handling is a beautiful thing, and no one expected 
it would be both feature-complete and highly-optimized in the same 
build.  Optimization will take some time.

But how much time is the question.

I had suggested they consider a 64-bit build of v6.7 for Linux and 
Server (I tend to use mostly standalones for CGI), but after reviewing 
the prospect the team felt that it would be too much effort for a 
version we all hope will be short-lived.

That said, it can only be short-lived to the degree that we can optimize 
v7, so until I hear more about the optimization effort it seems we're in 
a chickens-and-eggs situation:  we want to have the smallest number of 
builds to maintain and test (ideally just 7 & 8 for a while), but we 
need to be able to handle the same work we've done with v6.7.

Of course I'll relay here any news on optimization as I learn more....

-- 
  Richard Gaskin
  LiveCode Community Manager
  richard at livecode.org