| RE: [eclipse.org-requirements-council] Scaling Up: Multi-core and 64-bit support |
|
Let me share a couple of data points: At the recent BIRT 2.0 release review,
there was discussion that report generation required sorting gigabytes of data
that could not be kept in memory due to traditional 32-bit addressing. So, the
sorting algorithms were modified to write to disk which is much slower than
using the 64-bit memory address space. A request from a large enterprise ISV was
recently routed to me. This scenario involved a Java based payroll application
run on Windows desktop with multiple threads and need for handling large
amounts of data. Given that Eclipse on Win64 isn’t available, this
application had to limit itself to using 32-bit address space resulting in
degraded performance. We do not want to force users to upgrade
to 64-bit but make 64-bit easy to adopt for those that want to. Incidentally,
starting around the middle of 2006 almost all processors will be multi-core and
64-bit enabled. The only question is how effectively the software
infrastructure can exploit the underlying processor capabilities. In this, the
Eclipse ecosystem can take a leadership role. My team has provided Eclipse on 64-bit
(both x86_64 and IPF) for Linux for a year and a half. I’ll ask them to
make Eclipse on Win64 available in time for Eclipse 3.2. However, the Eclipse /
Win64 support is merely necessary, not sufficient for the software to take
advantage of processor’s multi-core and 64-bit features. For Eclipse ecosystem
to provide leading software capable of exploiting the multi-core and 64-bit
memory address space, we will need to diligently seek opportunities and provide
the right APIs all the way up the stack. So, I’d request including multi-core
and 64-bit support in the Scaling Up theme and request each top level project
to identify areas that would need to be reworked to take advantage of the
processor’s multi-core and 64-bit capabilities. Comments / feedback are welcome, Thanks Anurag |