Would it make a large difference? Is it worth doing? Hard to implement?

Really the only reason to create a 64 bit client would be to get access to more memory. But since we would need to maintain a 32 bit client anyway (we still have a lot of Windows XP users and will have for quite some time) then we need to keep the overall memory footprint in line with what a 32 bit client is capable of.

The server is already 64 bit and has been since 2008 (see this dev blog) for exactly this reason. Each blade in TQ has 32 GB of memory and runs 4 nodes, so on average each node has access to 8 GB of memory. At startup then each node uses approx. 700 MB of memory. Nodes with little traffic end up using about 950 MB, most common is 2-3 GB, and then there is normally a handful of nodes that use more than 6 GB (Jita on a busy day, nodes that host WH constellations, nodes where large fleet fights occur).

Since the server is already 64 bit then all code, except the rendering and audio engines and related middleware, is already 64 bit capable. To date then we don't have 64 bit versions of all the needed middleware and we haven't really dug into what it would take to make the rendering engine 64 bit.

I thought you guys already sent a message to the XP users with that whole boot.ini thing

Want 64-bit Eve?

Just load Eve twice. Problem solved.

What was so hard about that?

Congratulations, you just invented 33-bit Eve. Now load Eve 4 billion more times and you'll have 64-bit Eve.


MDD

i5's are selling in NA for under $500.
32 bit is on its way out. It just needs another year or so.

32+32=64
Programming is that simple.

Nodes with little traffic end up using about 950 MB, most common is 2-3 GB, and then there is normally a handful of nodes that use more than 6 GB (Jita on a busy day, nodes that host WH constellations, nodes where large fleet fights occur).

Interesting. Do W-space systems consume more memory than your average system? Or is it a case where many WH systems are mapped to one node (because overall low per-system activity?)

Please, step away from the keyboard before you type something else that dumb.

Really the only reason to create a 64 bit client would be to get access to more memory. But since we would need to maintain a 32 bit client anyway (we still have a lot of Windows XP users and will have for quite some time) then we need to keep the overall memory footprint in line with what a 32 bit client is capable of.

The server is already 64 bit and has been since 2008 (see this dev blog) for exactly this reason. Each blade in TQ has 32 GB of memory and runs 4 nodes, so on average each node has access to 8 GB of memory. At startup then each node uses approx. 700 MB of memory. Nodes with little traffic end up using about 950 MB, most common is 2-3 GB, and then there is normally a handful of nodes that use more than 6 GB (Jita on a busy day, nodes that host WH constellations, nodes where large fleet fights occur).

Since the server is already 64 bit then all code, except the rendering and audio engines and related middleware, is already 64 bit capable. To date then we don't have 64 bit versions of all the needed middleware and we haven't really dug into what it would take to make the rendering engine 64 bit.

What are the chances of seeing a pic of Tranquility? It's like nerd ****, you see.

32+32=64
Programming is that simple.

Interesting. Do W-space systems consume more memory than your average system? Or is it a case where many WH systems are mapped to one node (because overall low per-system activity?)

I pray this is just a troll otherwise you should never be allowed within 100 yards of a computer.... ever

for the rest of life

and even in death

32+32=64
Programming is that simple.

One aspect I have always been curious about is the actual systems themselves from a coding point of view. Are they large, square zones with x, y, and z axis; or perhaps spherical in design with the main star being the focal point? And while I have read how people have drifted towards nothingness, does each system have a hard border that if you somehow reached it, you could not move forward?

Each solarsystem is composed of "grids" that are square boxes centred on a "primary" object loaded into space. As you move around and outside that grid a new grid is loaded. There is no limit to space.

can i fly from one system to another (if i knew the direction ?)

Each solarsystem is composed of "grids" that are square boxes centred on a "primary" object loaded into space. As you move around and outside that grid a new grid is loaded. There is no limit to space.

can i fly from one system to another (if i knew the direction ?)

It did amuse me that the more serious and all knowing missed the humour here.

Each solarsystem is composed of "grids" that are square boxes centred on a "primary" object loaded into space. As you move around and outside that grid a new grid is loaded. There is no limit to space.

So, in theory, we could fly manually between systems, instead of using jumpgates? Wow. Ten years of deep-space travel.....

i5's are selling in NA for under $500.
32 bit is on its way out. It just needs another year or so.

You guys should write in physical boundaries in space where one system becomes another so that by crossing the boundary, you get transferred to the new system. Lol.

Please, step away from the keyboard before you type something else that dumb.

Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 32+32
64

Yeah, well you used to... I believe there ones someone who flew to Jove space using an old bug where you could warp to your maximum cap distance and they just spammed that for a LONG time....

Can someone confirm or call me a lying piece of dog turd please?

I'm guessing that's a cold aisle

(at least the closed off ceiling and doors and the floor vents hint at that)

Really the only reason to create a 64 bit client would be to get access to more memory. But since we would need to maintain a 32 bit client anyway (we still have a lot of Windows XP users and will have for quite some time) then we need to keep the overall memory footprint in line with what a 32 bit client is capable of.

The server is already 64 bit and has been since 2008 (see this dev blog) for exactly this reason. Each blade in TQ has 32 GB of memory and runs 4 nodes, so on average each node has access to 8 GB of memory. At startup then each node uses approx. 700 MB of memory. Nodes with little traffic end up using about 950 MB, most common is 2-3 GB, and then there is normally a handful of nodes that use more than 6 GB (Jita on a busy day, nodes that host WH constellations, nodes where large fleet fights occur).

Since the server is already 64 bit then all code, except the rendering and audio engines and related middleware, is already 64 bit capable. To date then we don't have 64 bit versions of all the needed middleware and we haven't really dug into what it would take to make the rendering engine 64 bit.

Werent you guys runnign two different clients (Diretx9 and Directx10) for a while before you did the update? Why not do 32 bit client and 64 bit client?

No, you will always stay in the same system. You need to trigger a session change via jumping to be transferred into the other system (thereby moving from one inventory location to another) since each system is managed separately and possibly on different nodes in the cluster.

Windows 9 is going to be 64bit only, with no support for 32bit software beyond VMs, so you've got until 2015

" Before Windows 7 even launched, Microsoft said that its successor, Windows 8, would be the very last version of Windows to support the old 32-bit architecture."

get your thinking caps on CCP...

Werent you guys runnign two different clients (Diretx9 and Directx10) for a while before you did the update? Why not do 32 bit client and 64 bit client?

64 bits is like 8 dollars in the 1800's

I'm guessing that's a cold aisle

(at least the closed off ceiling and doors and the floor vents hint at that)

Really the only reason to create a 64 bit client would be to get access to more memory. But since we would need to maintain a 32 bit client anyway (we still have a lot of Windows XP users and will have for quite some time) then we need to keep the overall memory footprint in line with what a 32 bit client is capable of.

The server is already 64 bit and has been since 2008 (see this dev blog) for exactly this reason. Each blade in TQ has 32 GB of memory and runs 4 nodes, so on average each node has access to 8 GB of memory. At startup then each node uses approx. 700 MB of memory. Nodes with little traffic end up using about 950 MB, most common is 2-3 GB, and then there is normally a handful of nodes that use more than 6 GB (Jita on a busy day, nodes that host WH constellations, nodes where large fleet fights occur).

Since the server is already 64 bit then all code, except the rendering and audio engines and related middleware, is already 64 bit capable. To date then we don't have 64 bit versions of all the needed middleware and we haven't really dug into what it would take to make the rendering engine 64 bit.

3 pages to think something up and that's what you brought to the table?

When people figure out that a 64 bit client will load a grid or change session faster than the people waiting for them in the bubble camp, you won't need an x32 client any more.

I have an old x32 WinXP system running a single core CPU with 1GB RAM and a x64 Win7 8 core system with 4GB RAM and there IS a difference.

(aside from the graphics from the latter .... "my God, it's full of stars.....")

Just going from a 32bit to a 64bit coordinate system should increase the free navigation on the order of 4.3bil times in each direction; plus and minus. That could encompas all of the current Eve Universe, depending on the scale used.

Just partition that out and have system demarcation grids to autoload the system you are closest too and allow freewarp between systems without using stargates.

Of course, it would take a BS 6 hours per light year to get anywhere.
An hour and a half per light year for non-rigged Cov Ops.

When people figure out that a 64 bit client will load a grid or change session faster than the people waiting for them in the bubble camp, you won't need an x32 client any more.

I have an old x32 WinXP system running a single core CPU with 1GB RAM and a x64 Win7 8 core system with 4GB RAM and there IS a difference.

The coordinate system in EVE is 64 bit and so are item IDs in the database, and so on and so forth. Being 32 bit only restricts the memory that the client has access to.

SSD: This is the best thing you can do for your computer. I have a three-year old laptop that I recently upgraded by replacing the spindle disk with an SSD (and upgraded from 2 GB to 8 GB RAM). It's a "new" machine.

Graphics card: This is the next-best thing you can do for your computer (if you play games). But do note that you want to buy from the high-end of a line of cards; if you need to buy something less expensive then you might be better off buying the high-end card from from the next line below what you really wanted.

Would it make a huge difference over an existing rather higher end conventional HDD?

So, interpreting you right, of cards A, B, and C (A being best, B being second best, and C being worst in terms of performance)

Getting top of the line B would be better than medium grade A given similar pricing?

I thought you guys already sent a message to the XP users with that whole boot.ini thing

That has nothing to do with 32 bit vs. 64 bit but has everything to do with single core vs. multi core. And also 1 GB of RAM vs. 8 GB, but 8 GB allows the operating system to cache much more aggressively. Also, I daresay that there are very different graphics cards in these two machines?

Let's start with the number of cores: Even just a dual core makes a tremendous difference. That way EVE can be running on one core but the operating system can do network and hard disk IO on the other, in addition to running other programs (such as your browser, media player, antivirus, ...). You don't get a lot in addition with 8 cores unless you are running a lot of programs.

More RAM: More RAM is better since that allows the operating system to cache more of the file system. As soon as you have started one client then starting the second client will be a lot faster since the file IO actually doesn't hit the disk.

SSD: This is the best thing you can do for your computer. I have a three-year old laptop that I recently upgraded by replacing the spindle disk with an SSD (and upgraded from 2 GB to 8 GB RAM). It's a "new" machine.

Graphics card: This is the next-best thing you can do for your computer (if you play games). But do note that you want to buy from the high-end of a line of cards; if you need to buy something less expensive then you might be better off buying the high-end card from from the next line below what you really wanted.

Yes an SSD is substantially faster. Think "no moving parts." They do wear out though. After a very long time.

Would it make a huge difference over an existing rather higher end conventional HDD?

So, interpreting you right, of cards A, B, and C (A being best, B being second best, and C being worst in terms of performance)

Getting top of the line B would be better than medium grade A given similar pricing?

SSD might not make a lot of difference compared to a high-end desktop drive, but it will make difference compared to a low-end drive and vastly outperforms spindle laptop drives.

Medium-line A will always be better than high-line C. Medium-line A will possibly be similar to high-line B but that would depend on the exact cards.

How much of the available coordinate system is actually used with the current Sol design though?

While going from 32bit to 64bit; did they change the "resolution" of the coordinate system? And/or, do they plan to more fully use the extra space provided? Or a combination of both?

Just the scale of the difference between the two is quite impressive. I did a test coordinate system at a 1-inch scale per tick and came up with a ~120k mile cube in 32 bit, and that changed to a ~100 ly cube when changed to 64 bit.

Interesting. Do W-space systems consume more memory than your average system? Or is it a case where many WH systems are mapped to one node (because overall low per-system activity?)

In my experience they probably host more WH systems as many of them don't even load between downtimes
I've had many many times where I was the one who loaded the hole late in the day.

when you try and log in you get a message that the system is still loading, then you try again and get in

It probably doesn't start loading until someone tries to enter.

When people figure out that a 64 bit client will load a grid or change session faster than the people waiting for them in the bubble camp, you won't need an x32 client any more.

I have an old x32 WinXP system running a single core CPU with 1GB RAM and a x64 Win7 8 core system with 4GB RAM and there IS a difference.

AMD Athlon 64 Processor 3200+ (2010 MHz)
Windows XP SP 3
1.00GB RAM

Vs

Windows 7 Pro SP1 64 bit
Intel Core i7-2760QM @w.40GHz
8.00 GB RAM

one day you sit in your white room, you start the dot-matrix LED projector and on all 4 walls around you see you the universe. You slide your hand into the glove and greet your corp mates. Ooops they sit in the middle of a fight. you slide your VR goggles over your eyes and accompany them in an epic battle .... things change.

That has nothing to do with 32 bit vs. 64 bit but has everything to do with single core vs. multi core. And also 1 GB of RAM vs. 8 GB, but 8 GB allows the operating system to cache much more aggressively. Also, I daresay that there are very different graphics cards in these two machines?

Let's start with the number of cores: Even just a dual core makes a tremendous difference. That way EVE can be running on one core but the operating system can do network and hard disk IO on the other, in addition to running other programs (such as your browser, media player, antivirus, ...). You don't get a lot in addition with 8 cores unless you are running a lot of programs.

More RAM: More RAM is better since that allows the operating system to cache more of the file system. As soon as you have started one client then starting the second client will be a lot faster since the file IO actually doesn't hit the disk.

SSD: This is the best thing you can do for your computer. I have a three-year old laptop that I recently upgraded by replacing the spindle disk with an SSD (and upgraded from 2 GB to 8 GB RAM). It's a "new" machine.

Graphics card: This is the next-best thing you can do for your computer (if you play games). But do note that you want to buy from the high-end of a line of cards; if you need to buy something less expensive then you might be better off buying the high-end card from from the next line below what you really wanted.

SSD might not make a lot of difference compared to a high-end desktop drive, but it will make difference compared to a low-end drive and vastly outperforms spindle laptop drives.

Medium-line A will always be better than high-line C. Medium-line A will possibly be similar to high-line B but that would depend on the exact cards.

Don't listen to CCP Explorer

x86-64 has more general purpose registers than the 32bit variant which allows your processor to keep more variables "on hand" and requires fewer (comparatively slow) lookups in cache or memory. This can result in a real performance improvement.

The available extensions were also streamlined with the introduction of x86-64 processors (tossing x87, MMX and 3DNow! out of the window; guaranteeing availability of SSE & SSE2) which mattered a lot when they first were released (as SSE2 was not something a programmer could rely on having available on 32bit processors - AMD didn't support it in their Athlons right until the introduction of their AMD64 line in 2003).
However, (in contrast to WoW) EVE does already require SSE2 (and as such does not benefit from its guaranteed availability on x86-64) so I guess the number of Athlon xp users has dropped to such low levels that making SSE2 a requirement is acceptable even for 32bit software.

Generally EVE seems to be much less CPU-bound than other MMOs (I don't know what Rift exactly does with all my CPU cycles but it sure loves churning through them, WoW is also relatively CPU heavy) so I doubt we would see a much of a benefit.

Very rough benchmark's of WoW's 64bit (beta) client showed it to give ~10% more FPS than the 32bit version.

For EVE SSD drives do not impact the game play much at all. Your patch time is faster. And game startup is much faster. Almost no waiting between clicking the play button and getting the log on screen. But that is about it. In game loading the inventory and market screens is a bit faster but a lot of that info comes from the server so you still have to wait for the server packets to arrive.
All in all the game play experience is about the same with a conventional drive or a SSD drive.

One of the main reasons I was looking is the speed up of the CQ time. If it loads fast enough I often don't bother switching to the hangar view as I prefer the CQ view, It just loads a bit slow for me. I'm currently running this: WD500 etc etc 7200 rpm. So I'm more curious what kind of a speed boost putting eve on an a SSD would be. Granted it isn't a terrible drive, but it isn't super top of the line either.

Really the only reason to create a 64 bit client would be to get access to more memory. But since we would need to maintain a 32 bit client anyway (we still have a lot of Windows XP users and will have for quite some time) then we need to keep the overall memory footprint in line with what a 32 bit client is capable of.

The server is already 64 bit and has been since 2008 (see this dev blog) for exactly this reason. Each blade in TQ has 32 GB of memory and runs 4 nodes, so on average each node has access to 8 GB of memory. At startup then each node uses approx. 700 MB of memory. Nodes with little traffic end up using about 950 MB, most common is 2-3 GB, and then there is normally a handful of nodes that use more than 6 GB (Jita on a busy day, nodes that host WH constellations, nodes where large fleet fights occur).

Since the server is already 64 bit then all code, except the rendering and audio engines and related middleware, is already 64 bit capable. To date then we don't have 64 bit versions of all the needed middleware and we haven't really dug into what it would take to make the rendering engine 64 bit.

How many blades are there?

We preload the systems that normally have the highest population but other systems are loaded on demand.

Would it make a huge difference over an existing rather higher end conventional HDD?

So, interpreting you right, of cards A, B, and C (A being best, B being second best, and C being worst in terms of performance)

Getting top of the line B would be better than medium grade A given similar pricing?

i5's are selling in NA for under $500.
32 bit is on its way out. It just needs another year or so.