| Pages: 1 2 :: [one page] |
|
|
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
HippoKing
   |
Posted - 2005.12.29 22:31:00 -
[1]
part of the hardware upgrades include moving to 64 bit architecture. this obviously updating a lot of the server software
i was just wondering:
How long does it take (man hours) to update the server software?
How many man hours would it take to do 64bit client software?
Are there any plans to do so?
|
Nyphur
|
Posted - 2005.12.29 22:34:00 -
[2]
It's not a case of simply upgrading the software. A lot of work would need to be done in order to make the most of the 64 bit processors some people have.
|
Sakira LeCastantas
|
Posted - 2005.12.29 22:36:00 -
[3]
Omg I want an eve client running 64-bit 
my 64-bit amd-proccie would get some use then lol
____________________________________________________
Turbo-Mode
The sig I had before had no hills, hail Justus Imperius |
HippoKing
|
Posted - 2005.12.29 22:42:00 -
[4]
 Originally by: Nyphur
It's not a case of simply upgrading the software. A lot of work would need to be done in order to make the most of the 64 bit processors some people have.
i recognise it would be a pretty large amount of work - i was just wondering how large exactly, and how much of the work would already have been completed by updating the server software (which is being done)
the obvious problems are:
not everyone uses 64 bit processors (and many of those who do don't use a 64bit OS)
it means keeping 2 active versions of the client at any one time
|
babyblue
|
Posted - 2005.12.29 22:43:00 -
[5]
If it's coded properly, it should just be a recompile to x64 target  .
The main trouble is that you have to "touch" all code paths, to fully test it. This is a VERY time consuming process.
|
Nyphur
|
Posted - 2005.12.29 22:44:00 -
[6]
I'll bet they could make a 64 bit version of the core rendering engine without a serious amount of work. Then they'd have a 64 bit client and a 32 bit client and you could run whichever one you want.
The source engine just released a 64 bit version.
|
Tar om
|
Posted - 2005.12.29 22:44:00 -
[7]
Edited by: Tar om on 29/12/2005 22:44:20
Another question would be: "How much of an improvement in performance would you get from a 64 bit client?" It seems that the server needs 64bit because the single threads which run a system (or more) are reaching the limits of addressable memory under 32bits, is the client hitting similar limits?
EVE certainly benefits from a hike in raw CPU "power" (CPU power being something quite hard to quantify), but maybe CCP would be better rewarded by rewriting the graphics system to take advantage of hardware acceleration available from modern graphics cards rather than going 64 bit?
Tar om
--
We are the Octavian Vanguard www.octavianvanguard.net
"The belief in the possibility of a short decisive war appears to be one of the most ancient and dangerous of human illusions." |
HippoKing
|
Posted - 2005.12.29 22:45:00 -
[8]
Originally by: babyblue
If it's coded properly, it should just be a recompile to x64 target
i've never coded anything (and my code is pretty simple - nothing like a game engine) into anything but x86 - i kinda assumed it would be harder than that to make it x64
|
babyblue
|
Posted - 2005.12.29 22:48:00 -
[9]
Originally by: HippoKing
Originally by: babyblue
If it's coded properly, it should just be a recompile to x64 target
i've never coded anything (and my code is pretty simple - nothing like a game engine) into anything but x86 - i kinda assumed it would be harder than that to make it x64
Well x64 is shorthand for 64 bit. Compile to target, fix the warnings then spend six months testing.
|
HippoKing
|
Posted - 2005.12.29 22:48:00 -
[10]
Originally by: Nyphur
The source engine just released a 64 bit version.
thats where i got the idea 
theres a 64bit version of far cry floating around as well
|
|
|
babyblue
|
Posted - 2005.12.29 22:50:00 -
[11]
Originally by: HippoKing
Originally by: Nyphur
The source engine just released a 64 bit version.
thats where i got the idea
theres a 64bit version of far cry floating around as well
Ahh. I bought farcry, installed it, went for a swim (the beach just looks ******* gorgeous), then didn't play it any more. I'm saving it for a future cold winter evening.
|
Cairo dog
|
Posted - 2005.12.29 22:51:00 -
[12]
Originally by: babyblue
Originally by: HippoKing
Originally by: Nyphur
The source engine just released a 64 bit version.
thats where i got the idea
theres a 64bit version of far cry floating around as well
Ahh. I bought farcry, installed it, went for a swim (the beach just looks ******* gorgeous), then didn't play it any more. I'm saving it for a future cold winter evening.
I've got an AMD 64 bit but when I tried that Far-Cry 64 bit it never worked :( Never got round to trying to fix it though.
-------------------------------------
The Holy God of Yemen ( It's a real place! Why has knowone ever heard of it?)
|
Fooball
|
Posted - 2005.12.29 22:52:00 -
[13]
Although you wouldn't get everything out of the version compiled against the 64-bit Windows and DirectX libraries, those parts would act faster. The more of the Client is written in high level languages and with good level of abstraction and with good style the easier it also is to compile.
Some software has been ready in almost like a snap of fingers. However the 64-bit Windowses are more like intermediate versions with their current driver support etc. It's better to wait for Vista. 
|
Ukucia
|
Posted - 2005.12.30 06:57:00 -
[14]
Edited by: Ukucia on 30/12/2005 06:57:30
Originally by: Fooball
It's better to wait for Vista.
Or you could wait for there to be a compelling reason to upgrade to 64-bit on the desktop.
Only environments I'm aware of that actually benefit from real 64-bit (not just the faster 64-bit processors) are very large server apps, like Eve's servers. There's very few times when being able to count to 18,446,744,073,709,551,615 is handy on a desktop.
|
Embattle
|
Posted - 2005.12.30 07:04:00 -
[15]
64bit Eve on the client side isn't needed.
-----------
Navy Raven just went up in smoke.....nuts. |
Nyphur
|
Posted - 2005.12.30 07:15:00 -
[16]
Originally by: Embattle
64bit Eve on the client side isn't needed.
Considering 32 bit processors are being completely left behind on the market, yes it is. 64 bit game clients will be coming out for all major games, I gather. Eve should not be any different.
|
Ardipithecus Ramidus
|
Posted - 2005.12.30 07:24:00 -
[17]
Oh, so just do it because everyone else is doing it? I prefer to have all the devs working to make one client work better, not to split them between two different versions.
The last thing I want is for CCP to start doing what all the other companies out there are doing simply because they are doing it. If they do something like issue a second version of the client, there'd better be a compelling technical reason to do it, not just a "everyone else is doing it." The system is too tempermental to be tampered with on a whim. CCP does an excellent job, I wouldn't want them to scramble for something that adds little to no functionality for the end user.
|
Nyphur
|
Posted - 2005.12.30 07:29:00 -
[18]
Originally by: Ardipithecus Ramidus
The last thing I want is for CCP to start doing what all the other companies out there are doing simply because they are doing it.
How about to improve performance?
|
Steven Dynahir
|
Posted - 2005.12.30 08:32:00 -
[19]
Quote:
Another question would be: "How much of an improvement in performance would you get from a 64 bit client?" It seems that the server needs 64bit because the single threads which run a system (or more) are reaching the limits of addressable memory under 32bits, is the client hitting similar limits?
Let's assume from former experience..
Setup1: Opteron, 7800GTX, WinXP x32, HL2 x32, FPS 100
Setup2: Opteron, 7800GTX, WinXP x64, HL2 x32, FPS 100
Setup3: Opteron, 7800GTX, WinXP x64, HL2 x64, FPS 115
In this case, overal increase when switching to full x64 was 15%. This might be the same case for EVE client, so expected performance increase might be near to 20% (I think EVE is more processor heavy than HL2, which is graphics heavy).
And in the case above, only thing happening was that the processor worked on native x64 code, and the processor works better with it.
---
Home, sweet home. |
TerrorWOLF
|
Posted - 2005.12.30 08:32:00 -
[20]
I think like 95% to 97% are running 32bit systems. And upgrading the processor isn't enough you need to upgrade the OS all drivers (64bit for XP are to loved from hardware manufacturers). The 64bit client will be a necessary when 50% or more are running 32bit systems and most of people don't buy a new PC every year.
May Your Death Be Slow And Painful
|
|
|
Avon
|
Posted - 2005.12.30 09:33:00 -
[21]
I went 64bit because it reminded me of my old Commodore 64.
Oh, and because the 64bit version of my 3d software runs 25%+ faster than the 32bit version.
______________________________________________
The Battleships is not and should not be a solo pwnmobile - Oveur |
Nyphur
|
Posted - 2005.12.30 09:39:00 -
[22]
Originally by: Avon
I went 64bit because it reminded me of my old Commodore 64.
Oh, and because the 64bit version of my 3d software runs 25%+ faster than the 32bit version.
I went 64 bit because I am stupid. Seriously, I got the Socket 754 Athlon 64 3000+ when it came out. Emphasis on the "Socket 754". I can't upgrade this thing without getting a new motherboard too. Not that it'll matter because they're doing away with socket 939 soon too.
I wouldn't have been annoyed but some major events delayed the uptake of 64 bit architecture into the software market. By the time anything decent I use has a 64 bit client comes out, it'll be time to upgrade (read: Throw this piece of crap out).
|
Testy Mctest
|
Posted - 2005.12.30 09:41:00 -
[23]
Originally by: Sakira LeCastantas
Omg I want an eve client running 64-bit
my 64-bit amd-proccie would get some use then lol
QFT!
And there are a fair few games that have both 32 and 64 bit versions running at the same time, afaik, such as the aforementioned source.
Educating Eve forum denizens as to the error of their ways since 2005. |
Rhyslin
|
Posted - 2005.12.30 09:52:00 -
[24]
I am not familiar with the x64 architecture, only with the architecture of a different 64-bit processor. However, it is not necessarily the case that all 64 bit apps will get a speed increase.
1) 64-bit h/w can generally run a 32-bit application without any speed degradation. This is usually a design constraint because almost all applications will not get recompiled for a long time, and you'd lose speed benchmarks during the interim.
2) 64-bit math can usually be done in a 32-bit application without making the whole application 64-bit.
3) A 64-bit application (generally) uses what is called an LP64 model, which means that longs and pointers become 64-bits. This means that data structures generally become bigger. This means they have higher memory consumption while running, as well as worse locality of reference, thus potentially increasing paging, and thus decreasing performance. Also, depending on the instruction set, loading a 64-bit pointer may take more time.
4) If data is to be stored on disk, and accessed by both 32-bit and 64-bit apps, you have to be careful that your data structures didn't change size. Also, if you were sloppy, and used the 32-bit assumption that a C long == int, your code will break.
5) The big win for 64-bit apps is with the amount of memory that can be accessed through a pointer without using some sort of application-based caching/paging. This is why it is often said that 64-bit is only of use on server systems, which have need of > 2 or 4 GB of address space (can depend on the processor and OS architecture).
So, that's why it's not clear that the client needs to be 64-bit. And given the effort at porting, and at testing both versions, it's not clear that it's a big win.
|
Avon
|
Posted - 2005.12.30 10:04:00 -
[25]
Originally by: Nyphur
Originally by: Avon
I went 64bit because it reminded me of my old Commodore 64.
Oh, and because the 64bit version of my 3d software runs 25%+ faster than the 32bit version.
I went 64 bit because I am stupid. Seriously, I got the Socket 754 Athlon 64 3000+ when it came out. Emphasis on the "Socket 754". I can't upgrade this thing without getting a new motherboard too. Not that it'll matter because they're doing away with socket 939 soon too.
I wouldn't have been annoyed but some major events delayed the uptake of 64 bit architecture into the software market. By the time anything decent I use has a 64 bit client comes out, it'll be time to upgrade (read: Throw this piece of crap out).
My main box is a 3400+ on 754 and is pretty damn fast.
I went 754 by choice too. (cost:performance)
______________________________________________
The Battleships is not and should not be a solo pwnmobile - Oveur |
space fox
|
Posted - 2005.12.30 10:15:00 -
[26]
amd venice core 3200+ 64 bit, socet 939, its a dream to use after my 1.8
|
Bligger II
|
Posted - 2005.12.30 10:51:00 -
[27]
IF CCP is thinking about a x64 client it might be a good idea to publish a beta client very early for an open beta to be used on your own risk. I am shure I am not the only one who would give it a try and help testing
|
HippoKing
|
Posted - 2005.12.30 11:00:00 -
[28]
Originally by: Cairo dog
Originally by: babyblue
Originally by: HippoKing
Originally by: Nyphur
The source engine just released a 64 bit version.
thats where i got the idea
theres a 64bit version of far cry floating around as well
Ahh. I bought farcry, installed it, went for a swim (the beach just looks ******* gorgeous), then didn't play it any more. I'm saving it for a future cold winter evening.
I've got an AMD 64 bit but when I tried that Far-Cry 64 bit it never worked :( Never got round to trying to fix it though.
you have to be running windows x64 to use it i think
|
n1r4
|
Posted - 2005.12.30 11:03:00 -
[29]
Originally by: space fox
amd venice core 3200+ 64 bit, socet 939, its a dream to use after my 1.8
I had a athlon xp 1.8 and upgraded to a opteron 144 OC @ 2.8 now I can finally max out on games 
|
Gothikia
|
Posted - 2005.12.30 11:13:00 -
[30]
i would just like to state that it isn't as easy as some people in this thread have made it out to be. I use fairly the same technology as CCP does for EVE and porting EVE to x64 is no small task. The biggest challenge they currently have is porting stackless python to x64, which is why they have brought in Christian Tismer (the guy who created stackless) to help them out. Hopefully Tismer will release some news on x64 stackless soon
And yeah, EVE could seriously do with a graphics overhaul. I think its long overdue and i have a feeling we might see the start of it with KALI, but thats just based on all the dev blogs, news articles, dev posts and things that were said at fanfest. 
[IDEA] Player Created Empires |
|
|
Embattle
|
Posted - 2005.12.30 12:33:00 -
[31]
Originally by: Nyphur
Originally by: Embattle
64bit Eve on the client side isn't needed.
Considering 32 bit processors are being completely left behind on the market, yes it is. 64 bit game clients will be coming out for all major games, I gather. Eve should not be any different.
When you understand what 64bit processors actually do over 32bit then you'll understand my reply better.
-----------
Navy Raven just went up in smoke.....nuts. |
Taketa De
|
Posted - 2005.12.30 13:55:00 -
[32]
The place where 64 bits are really needed is when you need to have more then 3-4 gigs of ram in your computer and for apps that use those ammounts. The other applications that really benifit are those that used to do 64 bit math on 32 bit processors. Those will speed up nicely.
Every other port to 64 bits could be a bit faster, could be a bit slower but since most of the math CCP uses on the client will probably be 32 bit (better performance) the switch to 64 bit probably won't make much of a difference.
64 != faster. It just means the length of registers and memory adresses are bigger. Like a poster above wrote this can increase the memory size your application needs and it will also increase the size of your application on disk. If you did something like install it on a system with low memory already your performance will suffer.
Late addin:
Just noticed I forgot to mention the possible speedup due to more registers being available directly (and not just by a processor cheating and doing stuff like register renaming), so for some apps that can give some speedup as well.
|
Bubba Love
|
Posted - 2005.12.30 14:26:00 -
[33]
Quote:
3) A 64-bit application (generally) uses what is called an LP64 model, which means that longs and pointers become 64-bits. This means that data structures generally become bigger. This means they have higher memory consumption while running, as well as worse locality of reference, thus potentially increasing paging, and thus decreasing performance. Also, depending on the instruction set, loading a 64-bit pointer may take more time.
Yeah, I've often wondered what performance impact this alone might have.
However, AMD64 has 16 general purpose registers as opposed to 8. This should reduce slow stack usage whilst making function calls and during loops.
Does anyone have any meaningful benchmarks showing the comparative performance of 32-bit/64-bit on x86? I'm more interested in general computation benchmarks as opposed to cherry picked examples that can be skewed by SIMD, etc.
civire chicks are the best... |
Bubba Love
|
Posted - 2005.12.30 15:03:00 -
[34]
Another worthwhile feature of AMD64 is the improved floating point maths support. AMD64 allows the SSE2 registers to be used for faster floating point. The old 32-bit stack approach was a nightmare for compilers to generate efficent code.
I don't work in the games industry so don't know how much of the 3D pipeline is done by the GPU or CPU.
So all in all, 64-bit x86 does seem to offer some attractive benefits - IMHO. Unfortunately there's too many marketing droids in this area telling everyone they must do 64-bit.
civire chicks are the best... |
BBQ
|
Posted - 2005.12.30 15:52:00 -
[35]
The other addition that AMD introduced with the x64 processor is an increase in registers.
This means that pushing a register into memory for re-use and then getting it back later is reduced, this saves code and gives a bit improvement in speed as well. I think this is the reason that people see a speed improvement when running x32 apps on xp64 as the register swapping that was needed under xp32 to multitask happens alot less often now.
The compiler needs to take advantage of this feature though.
<< Insert whitty sig here >>
|
Avon
|
Posted - 2005.12.30 16:52:00 -
[36]
Originally by: Bubba Love
Does anyone have any meaningful benchmarks showing the comparative performance of 32-bit/64-bit on x86? I'm more interested in general computation benchmarks as opposed to cherry picked examples that can be skewed by SIMD, etc.
The only benchmark which I was interested in was Cinebench because I could directly compare 32bit and 64bit performance of the application I intended to use.
I was surprised at the difference. I really didn't expect a huge speed-up, I was more interested in being able to use more memory directly so I could overcome some of the limitations I had encountered when creating highly detailed scenes.
On my system the 64bit version of the benchmark ran just over 25% faster than the 32bit version.
Probably not very scientific only using one benchmark, but I was only interested in the performance of this one application. How everything else runs is a side issue ;)
______________________________________________
The Battleships is not and should not be a solo pwnmobile - Oveur |
Mikha'il Pelegius
|
Posted - 2005.12.30 17:36:00 -
[37]
Quote:
I am not familiar with the x64 architecture, only with the architecture of a different 64-bit processor. However, it is not necessarily the case that all 64 bit apps will get a speed increase.
1) 64-bit h/w can generally run a 32-bit application without any speed degradation. This is usually a design constraint because almost all applications will not get recompiled for a long time, and you'd lose speed benchmarks during the interim.
2) 64-bit math can usually be done in a 32-bit application without making the whole application 64-bit.
3) A 64-bit application (generally) uses what is called an LP64 model, which means that longs and pointers become 64-bits. This means that data structures generally become bigger. This means they have higher memory consumption while running, as well as worse locality of reference, thus potentially increasing paging, and thus decreasing performance. Also, depending on the instruction set, loading a 64-bit pointer may take more time.
4) If data is to be stored on disk, and accessed by both 32-bit and 64-bit apps, you have to be careful that your data structures didn't change size. Also, if you were sloppy, and used the 32-bit assumption that a C long == int, your code will break.
5) The big win for 64-bit apps is with the amount of memory that can be accessed through a pointer without using some sort of application-based caching/paging. This is why it is often said that 64-bit is only of use on server systems, which have need of > 2 or 4 GB of address space (can depend on the processor and OS architecture).
So, that's why it's not clear that the client needs to be 64-bit. And given the effort at porting, and at testing both versions, it's not clear that it's a big win.
QFT. 64bit is a great peice of hardware with a lot of capability for memory handling. But if our desktops are not using more than 4-5 Gigs of RAM we have no use for it. AMD64 is an extension of current memory allocation and management, and to force the clients into AMD64 mode would mean a slower client-side responce due to the additional pointer handling, in a system that doesn't have the additional RAM.
Since AMD64 (why is everyone ignoring the intel 64 version? x64 is x64) has the 32-bit calculation processing built into it, there isn't any slowdown during the 32-to-64 bit transition of code because it is still running the 32-bit natively via the new 64-bit instructions.
Don't push EVE in that marketing direction. 64Bit has it's place in large-scale servers (such as CCP's) and I feel it would make a great server-side impact. But not client-side. I'd rather see resources allocated into graphics, bug fixes, and a linux port (or at least CCP working with transgaming on cedega bug fixes).
----------------------
|
Nadec Ascand
|
Posted - 2005.12.30 17:46:00 -
[38]
/me run a Windows 32bit due to eve being 32bits
/me cry
Yeah im caldari... and yeah im flying a megatron...
Why coz maybe now only caldary are tough enough to fly those and evryone use caldari ship...
|
Bubba Love
|
Posted - 2005.12.30 19:14:00 -
[39]
Quote:
Since AMD64 (why is everyone ignoring the intel 64 version? x64 is x64)
When I say AMD64 I also mean EM64T which is Intel's 64-bit x86 extension. Thankfully, Intel's 64-bit implementation is largely compatible with AMD.
The trouble with the marketeers is that they are mixing up a lot issues into the whole 64-bit sales drive. 64-bit in itself just increases the amount of addressible memory (2 to the power of 64 = 18,446,744,073,709,551,616) and also the largest integer (whole number). This change shouldn't yield any performance benefit unless your application requires vast amounts of memory (think large server database) or computes astronomically large numbers (here we can probably exclude EVE).
The real performance payoff with 64-bit x86 are all the various architectural tweaks made to the aging x86 instruction set, notably more general purpose registers, better floating point arrangement, etc. If i recall correctly the original x86 design dates back to the 4-bit 4004 which was designed to control traffic lights!
64-bit is nothing new, DEC Alpha servers were running 12 years ago. The Nintendo-64 also had a 64-bit cpu (MIPS R4300) which was 9 years ago. So it's all quite boring really.
civire chicks are the best... |
Jenny Spitfire
|
Posted - 2005.12.30 19:22:00 -
[40]
Originally by: Bubba Love
The real performance payoff with 64-bit x86 are all the various architectural tweaks made to the aging x86 instruction set, notably more general purpose registers, better floating point arrangement, etc. If i recall correctly the original x86 design dates back to the 4-bit 4004 which was designed to control traffic lights!
Dont forget the new compilers too! 
----------------
RecruitMe@NOINT! |
|
|
Ukucia
|
Posted - 2005.12.31 08:40:00 -
[41]
Edited by: Ukucia on 31/12/2005 08:41:05
Originally by: Mikha'il Pelegius
why is everyone ignoring the intel 64 version? x64 is x64
Because Intel's 64-bit processors were not 'x64' until recently.
Intel started with a new instruction set, called IA-64. This instruction set was a re-write, so it was not compatible with all the existing x86 programs. All existing x86 apps would have to be run through an emulator, or rewritten/recompiled for IA-64.
AMD came out with an instruction set which was an extention to x86, and thus compatible with it. Since it was compatible, AMD's instruction set 'won out' over Intel's.
Both Intel and AMD now use an instruction set that is basically AMD's.
|
Ukucia
|
Posted - 2005.12.31 08:52:00 -
[42]
Originally by: Jenny Spitfire
Originally by: Bubba Love
The real performance payoff with 64-bit x86 are all the various architectural tweaks made to the aging x86 instruction set, notably more general purpose registers, better floating point arrangement, etc. If i recall correctly the original x86 design dates back to the 4-bit 4004 which was designed to control traffic lights!
Dont forget the new compilers too!
To respond to both of you: What you're saying is true of any new processor family. The same things can be said about going from 386 to 486 to 586 and so on. In both cases, the chip manufacturers improved the microcode and added more optimizations to the chips, and new compilers were written to take advantage of the new chip features.
That's what I meant by my ealier comment about 64-bit mostly benefiting just from faster chips. The 64-bit chips are jumping to a new chip family. However, 64-bits are not required for this performance boost.
If the x86 folks were really serious about drastically improving performance, they'd take a look at the horrorshow that is MMX/SIMD/etc. I'm a fan of Altivec here: 128-bit wide registers let you do some really nice performance tweaks, and the separate VPU is much better than re-using the FPU.
(Disclaimer: it's been several years since I've worked this low level, so I don't know what Intel/AMD have done with MMX/etc recently...I just doubt it's changed much.)
|
|
|
| |
|
| Pages: 1 2 :: [one page] |