Tremulous Forum
General => General Discussion => Topic started by: bacon665 on May 06, 2009, 03:10:57 am
-
Hi, I noticed there was very little mention of x64 builds for winblows.
I have experience compiling on Unix/Linux and can do some basic code editing so heres the deal:
I have a new 64bit system and windows vista home premium x64 and id like to build the x64 binary packages on it so everyone can use it, but i need a little guidence in doing so. I wish to enable SSE3 and multithreading and my system has the following specs.
Proc: AMD Phenom x4(AM2+) 9950 Black edition.
Ram: 4 gig patriot Viper 1024mghz DDR2
Hard disk: (surely it wont take an extra 500 gigs)
Graphics:
Onboard - Radeon HD 3500
PCI-E - Nvidia 9600GT(not installed but available if needed for build)
Gigabyte ETH
HD audio.
Im even willing (should i get stuck) to let one of the devs use teamveiwer or VNC to work on it.
-
there isn't currently a 64 bit version of mingw for windows, so the 64 bit build will have to wait, though there isn't much benefit other than increased loading times.
-
there is a 64bit mingw lol.
its been out for a while now.
and yes you get an increase in the number of vectors processed per cycle. and now that explorer. exe has been divided and they added a program to control the compatability libs in windows you save on memory too. (even with the double sized pointers)
-
no reason why 64bit mingw shouldn't compile trem
talk to frak and doomagent they were looking into it a while back.
-
The x64 JIT won't compile on windows.
-
Please, it's "x86_64", not "x64."
-
It's not that simple: x64 is the name used by Microsoft, x86_64 is the original name used by AMD and also used in Linux. AMD switched to the name amd64, Intel called it originally EM64T and later Intel64. (If anybody still isn't confused now, all these names refer to the 64-bit extension of the ia32 architecture, but of course the name ia64 refers to a completely different architecture.)
-
The x64 JIT won't compile on windows
What about compiling the 32 bit version and linking it in the 64?
-
i hope ur moar thorough at inspecting ur code than ur quotes
j/k gl
-
What on earth could you possibly mean =P
-
i hope ur moar thorough at inspecting ur code than ur quotes
j/k gl
I seriously lol'd.
I'll volunteer my [64-bit Intel] system as well if it means getting a native x64 client for Windows.
-
I don't understand. Why are you concerned about fancy game file crap when you could be cranking up the actual game and enjoying it?
-
I don't understand. Why are you concerned about fancy game file crap when you could be cranking up the actual game and enjoying it?
Why are you spamming all threads with nonsense just to increase your post count?
-
The 32-bit JIT will NOT work on 64-bit systems, since it generates 32-bit code.
(Well I guess I could have that code run in a 32-bit code segment, but that would take more effort than just porting the JIT to x64 Windows :P)
-
You could run the JIT code in a separate 32 bit process and communicate via sockets, but that would probably be even slower than the interpreter.
-
All the 32bit API's are present in the 64 versions.
so native 32 bit code can run. and ive seen a couple threads on MSDN where the 64 called on a 32 bit process.
-
64bit process calling a 32bit process is very very different to 64bit code running 32bit code.
-
Either way im sure one of them can be done.
What about using AOT GNU Lightning or libJIT to change it over?
64-bit NGEN Optimizations
For the purposes of this article, I've referred to the JIT and NGEN together as the JIT. With the 32-bit version of the CLR, both the JIT compiler and NGEN perform the same optimizations. This is not the case for the 64-bit version, where NGEN does significantly more optimization than the JIT.
The 64-bit NGEN takes advantage of the fact that it can spend a lot more time compiling than a JIT can since the throughput of the JIT directly affects the response time of the application. I specifically mention the 64-bit NGEN in this article as it has been relatively well-tuned to work with C++-style code and it does some optimizations that greatly help C++, such as the Double Thunk Elimination optimization, which other JITs and NGENs do not do. The 32-bit JIT and the 64-bit JIT were implemented by two different teams within Microsoft using two different code bases. The 32-bit JIT was developed by the CLR team, whereas the 64-bit JIT was developed by the Visual C++ team and is based on the Visual C++ code base. Because the 64-bit JIT was developed by the C++ team, it is more aware of C++-related issues.
Double Thunk Elimination
One of the most important optimizations that the 64-bit NGEN performs is known as double thunk elimination. This optimization addresses a transition that happens when calling a managed entry point from managed code, through a function pointer or virtual call in C++ code compiled with the /clr switch. (This does not happen in /clr:pure or /clr:safe compiled code. ) This transition occurs because neither the function pointer nor the virtual call have the necessary information at the callsite to determine if they're calling into a managed entry point (MEP) or an unmanaged entry point (UEP).
For backwards compatibility, the UEP is always selected. But what if the managed callsite is actually calling a managed method? In this case, there would be a thunk that goes from the UEP to the target managed method, in addition to the initial thunk from the managed callsite to the UEP. This managed-to-managed thunk process is what is commonly referred to as the double thunk.
Source: http://msdn.microsoft.com/en-us/magazine/cc163855.aspx
could something like that be of use?
-
could something like that be of use?
no
-
could something like that be of use?
no
That means very little coming from you since you cant even seem to google for the 64bit MinGW
-
For anyone who else who does not know where to look.
Heres the MinGW 64 http://mingw-w64.sourceforge.net/
-
For anyone who else who does not know where to look.
Heres the MinGW 64 hxxp: mingw-w64. sourceforge. net/
Why are you obfuscating the links you post?
-
he isn't.
-
Blame Khalsa
-
Blame Khalsa
Well, maybe it should default to only obfuscate links in sigs?
-
would putting it in quote or a http:sourceforge.net/projects/mingw-w64/
?
ok so the [ link ] didnt work
i could just tell you to google "MinGW 64"
so how about back on topic.
If JIT wont compile is it possible to reconvert it to AOT?
With the extra headroom and increased amount of integers processed per clock inversion it shouldnt really impact game play.
And another question would be swapping the engine.
I noticed the old one was just an add on for the quake engine so you could use one of the hundreds of replacement engines right?
-
shut up
-
shut up
If you dont wish to contribute then why did you even post?
-
shut up
-
WTF is your problem?
-
WTF is your problem?
Replying only feeds into it.
But I think he might be implying that something you said is wrong or just noobish. (probably your last comment about replacing the engine, that's just a guess though)
-
...swapping the engine...
shut up
It's been discussed lots, go search.
-
Ive seen some of the threads about the OpenArena and a couple others floating around on source forge.
But JIT and AOT are just compilers not the engine.
I also seen a thread about a python based server, If the client was also migrated then there wont be much hassle at all as you would just install the 64bit windows binary of python and go about life.
-
shut up
-
Ok so I did some more reading and still havent found a reason for JIT not to work
But in the meantime i can still build a 32bit version with SSE3 SSE4a and NX Bit.
-
http://releases.mercenariesguild.net/client/ <-- has a 64bit build.
-
http://releases.mercenariesguild.net/client/ <-- has a 64bit build.
Hi, I noticed there was very little mention of x64 builds for winblows.
-
oh yeah, /me is blind. There are too many threads about 64 bit >_>.
-
But this should just show that its possible to Build for windows 64.
Unix linux and other Posix systems are rather easy to adapt.
./configure takes care of all that.
-
Only there is no ./configure in tremulous.
-
Thats because it uses the MinGW tool chain.
If it wasnt a pain in the ass to set up.....
#!/bin/sh
export CC=i586-mingw32msvc-gcc
export WINDRES=i586-mingw32msvc-windres
export PLATFORM=mingw32
exec make $*
Thats all thats in the build script
-
shut up
-
theres no reason for you to start the shutup shit.
the build chain for x64 is here:http://sourceforge.net/project/showfiles.php?group_id=202880&package_id=311650
should just have to set it up and change that to
export CC=i986-mingw32msvc-gcc
export WINDRES=i986-mingw32msvc-windres
export PLATFORM=mingw32to at leats make use of newer processor functions or
export CC=x86-64-mingw64msvc-gcc
export WINDRES=x86-64-mingw64msvc-windres
export PLATFORM=mingw64
and is this patch for smp even needed when you change to i786 or higher since theyre both smt/smp enabled anyway?
Index: Makefile
===================================================================
--- Makefile (revision 835)
+++ Makefile (working copy)
@@ -674,7 +674,7 @@
ifneq ($(BUILD_CLIENT),0)
TARGETS += $(B)/tremulous.$(ARCH)$(BINEXT)
ifneq ($(BUILD_CLIENT_SMP),0)
- TARGETS += $(B)/tremulous.$(ARCH)$(BINEXT)
+ TARGETS += $(B)/tremulous-smp.$(ARCH)$(BINEXT)
endif
endif