Adobe doesn't want me to run Flash on 64 bit linux?
broadcast.oreilly.com
broadcast.oreilly.com
It is hardly surprising that a large company doesn't see much ROI in tailoring a consumer oriented product for a tiny market segment. Given that Flash Player is losing relative and perhaps absolute web presence and the frequency with which Adobe must patch it for security vulnerabilities, creating a version for the tiny minority of consumers who use 64 bit linux for browsing doesn't make a lot of sense from an economic standpoint. The fact that the beta wasn't being brought up to date is probably a reflection of market realities rather than any bias against the platform, and given that a reasonable workaround was available (i.e. a 32bit version), it is hardly surprising that the overall project was dropped.
It is inevitable that Flash will not be everywhere - it will not even be on a significant portion of mobile devices, e.g. iphones.
The lack of 64-bit for Linux is just a symptom of what seems to be a problem at Adobe.
The reasons for a lack of 64 bit OSX support are left as an exercise for the reader.
Flash feels like a dead end more and more.
Until there's a viable competitor in the Linux space, Flash on x64 will continue to be a choice between several bad solutions.
The only thing that could change this would be if Arm CPUs started supporting the x64 instruction set. Then Android's position in the market would likely make a compelling business argument for a 64-bit Flash. I'm not holding my breath.
This is why we write portable code in higher-level languages that can be compiled for both architectures.
Not sure that Android is a motivating factor for Adobe to produce code for desktop Linux, though. Virtualized x64 compatibility would be slower than ARM, and Flash is already a dog on Android.
Do people run browser sessions that use huge amounts of memory?
EDIT: Is it standard practice to compile everything as 64-bit on AMD64? This is not the case on early 64-bit arch such as sparc and ppc. The reason for this is that compiling as 64-bit doubles the size of longs and pointers and is only an advantage when you need to address large amounts of memory.
For example if you run linux on ppc64 almost all of your userland is probably compiled 32bit.
compiling as 64-bit doubles the size of longs
and pointers
The reason for why apps don't get compiled to 64-bits has more to do with the effort required to port said apps to 64-bits.
Truth is running 64-bits apps yields other advantages than access to more than 4GB of memory - a 64-bits app has access to the processor's 64-bits instruction set and some architectures allow access to more general purpose registers, memory-mapped files are easier to implement (MongoDB, last time I tried it, was unusable on 32-bits) and performance of applications such as encoders/decoders/encryption software is increased.
A 64-bits Flash would clearly benefit from the transition, even if you don't have more RAM.
> Obese longs and pointers, imagine the horror
Take a break from javascript and look up how processor caches work, doubling the size of pointers increases cache pressure and can definitely make programs slower.
> allow access to more general purpose registers, memory-mapped files are easier to implement
I specifically mentioned more registers and a bigger address space. My question was whether this made a difference for web browsers.
I specifically mentioned more registers
Take a break from javascript and look up how
processor caches work
It is true in practice that 32-bits is all you'll ever need and you won't notice the difference, but modern browsers would get a healthy boost in performance (yes, 15% matters).
In my top post I said:
> Other than the fact that amd64 provides more GPRs?
You should read what you're replying to.
> Also, 32-bits apps running on top of 64-bits are running in an emulated 32-bits environment
That's bullshit, at least on AMD64. "Because the full 32-bit instruction set remains implemented in hardware without any intervening emulation, existing 32-bit x86 executables run with no compatibility or performance penalties" [0]
> but modern browsers would get a healthy boost in performance
Have you tested this?
Which is true if you're running a 32-bit kernel on top of the 64-bit processor.
If you're running a native 64-bit kernel, then the kernel needs a 32-bit emulated layer that runs between the native kernel and the userland application that handles virtual memory address translations(32-bit executables are still limited to 4 gigs of RAM, but can be physically located anywhere), system call translations, etc. That's a potential performance hit.
Mind you, when it comes to nvidia cards and the claims that newer versions of flash make about hardware video decoding, it's not funny anymore.
Increased effectiveness of ASLR (Address space layout randomization) and PIE (position independent executables) is one such reason. Using ASLR and 64 bit pointers can make some common classes of attack much more difficult, and potentially infeasible. I don't think mainstream linux distributions take full advantage of them yet, though.
And personally, yes, I could easily blow this limit if I allowed my normal browsing behavior to blossom (that is having lots of tabs I want to reference later and leaving them open).
What advantages does running a 64-bit browser on a 64-bit OS have over running a 32-bit browser on a 64-bit OS?
Do the 8 extra GPRs bring significant performance benefits?
Do individual browser processes need to address lots of memory?
That's interesting. Does it make up for the increased size of pointers? Caches are under a lot of pressure these days.
AMD64 is a weird arch. Is it possible to use 64bit instructions with a 32bit address space?
More from data sizes than code sizes, at least in most performance-critical applications. Sure, bigger pointers will lead to higher miss rates in caches that contain code, but that is unlikely to prove to be a bottleneck for real-world browser use (in the current version of the real world).
It's not ideal, but works fine for casual Flash website use.
If my main daily experience of dealing with your company is cursing at you when I restart software I feel forced to use (npviewer.bin), I'm probably going to look for alternatives to your other software as well.
I'm actually being serious - I don't have it installed on any of my computers and I've never been to a site that asked me to download it... But perhaps that's because it's mostly used for video streaming and in Australia we don't get any sites like Netflix, Hulu etc.