Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#172 closed Open task (fixed)

Change build/setup to x86 only

Reported by: Matthäus Wander Owned by: Matthäus Wander
Priority: Important Milestone:
Component: General Keywords:

Description (last modified by Matthäus Wander)

While the main components of CT2 are pure .NET assemblies, some plugins use native libraries. This raises the following question: which plattform(s) shall be targeted by the build/setup process?

We have the following possibilities:

  1. x86 and x64 separately
  2. AnyCPU
  3. x86

The x86/x64 solution works but requires some maintenance overhead, for example conditional references to DLLs. It is not overly complex, but as Visual Studio does not fully support conditional references, you have to use a text editor which is error-prone and annoying. Any other maintenance regarding build/setup is also somewhat affected (keeping a clean public solution file for example).

There is no real gain in providing an x64 version: it is not necessarily faster than the x86 version. x64 has some characteristics that can make it run faster than x86 (Int64 operations), but others that can make it run slower (larger assemblies, effectively halfed CPU cache). The CT2 brute-force key searcher proved to be much slower as x64 version than as x86. This may have different reasons (maybe the .NET C# x86 compiler optimizes better than the x64 one or maybe our code was better to optimize for x86), but trying to optimize for both architectures separately is too expensive and therefore no option for us. There may be applications that benefit from the large address space but as we explicitly want to fully support x86, we will design CT2 so that it is not necessary to have more than let's say 3 GB RAM. In summary: separate x86/x64 versions require some additional effort and do not provide any gain for us.

Using AnyCPU for all .NET assemblies may be a feasible option. To reference native DLLs you either need to use dynamic references or build a .NET wrapper (which may be referenced statically from CT2, but itself uses dynamic references to access either the x86 or x64 native DLL). Some time ago when we were using the setup project in Visual Studio 2008 this did not work, as you could not put both x86 and x64 DLLs in a single setup file. This was a limitation of the Visual Studio setup project type, which does not apply for MSBuild and its MSI setup (or other installers). The AnyCPU has the advantage of using only one build process, one setup file and no conditional references for any .NET component. Still, there is no real advantage of the AnyCPU target compared to the x86 target.

x86 runs on both, 32 and 64 Bit Windows versions. The advantage of the x86 target is, we do not have to worry about x64 DLLs at all: we simply use x86 for all .NET components and all libraries. This eases maintenance and testing. As explained above, x86 memory limitations are no issue for us and speed does not seem to degrade significantly (if at all).

Conclusion: switch to "x86 only" for now. Once there is proof that x64 significantly boosts performance, we may consider switching to AnyCPU and maintain native DLLs in x86/x64. Once 32 Bit Windows has no more relevance, we can switch to "x64 only".

Here is some more information on this topic:

Change History (9)

comment:1 Changed 10 years ago by Matthäus Wander

Description: modified (diff)

comment:2 Changed 10 years ago by Matthäus Wander

Description: modified (diff)

comment:3 Changed 10 years ago by Matthäus Wander

Description: modified (diff)

comment:4 Changed 10 years ago by Matthäus Wander

(In [2310]) Consolidating x64 and x86 build targets. Please use only "x86", see #172.

override-bad-extension: Bdev.Net.Dns.dll override-bad-extension: Bootstrapper.dll override-bad-extension: Bootstrapper.pdb override-bad-extension: CertificateLibrary.dll override-bad-extension: CertificateLibrary.pdb override-bad-extension: CertServices.dll override-bad-extension: CertServices.pdb override-bad-extension: Chord.dll override-bad-extension: Chord.pdb override-bad-extension: FullMeshDHT.dll override-bad-extension: FullMeshDHT.pdb override-bad-extension: FullMeshOverlay.dll override-bad-extension: FullMeshOverlay.pdb override-bad-extension: Gears4Net.dll override-bad-extension: Gears4Net.pdb override-bad-extension: LinkManager.dll override-bad-extension: LinkManager.pdb override-bad-extension: log4net.dll override-bad-extension: log4net.pdb override-bad-extension: msieve.dll override-bad-extension: MySQLDHT.dll override-bad-extension: MySQLDHT.pdb override-bad-extension: NativeCryptography.dll override-bad-extension: PapsClient.dll override-bad-extension: PapsClient.pdb override-bad-extension: PeersAtPlayBase.dll override-bad-extension: PeersAtPlayBase.pdb override-bad-extension: RUDP.dll override-bad-extension: RUDP.pdb override-bad-extension: Stun.dll override-bad-extension: Stun.pdb override-bad-extension: Util.dll override-bad-extension: Util.pdb override-bad-extension: WebDHT.dll override-bad-extension: WebDHT.pdb override-bad-extension: AnotherEditor.dll override-bad-extension: CrypWin.exe

comment:5 Changed 10 years ago by Matthäus Wander

(In [2311]) Consolidating x86 and x64 build targets, see #172.

  • changed Win32 target path of native libs
  • kept x64 configuration for future use

comment:6 Changed 10 years ago by Matthäus Wander

(In [2312]) fixed pathes, see #172

comment:7 Changed 10 years ago by Matthäus Wander

Though we can put both x86 and x64 native DLLs into one MSI file, it is not supported to create a common MSI AnyCPU installer. Thus, if in future we decide to change our solution from x86 to AnyCPU, we still will have to create two separate MSI installers, one for x86 and one for x64. Both will contain exactly the same CrypBuild binaries, so it will be sufficient to publish one common zip file.

Maybe in future MSI will add AnyCPU support (or we decide to use another installer). Anyway, having just the x86 build target now and going to AnyCPU in future is still the best choice.

comment:8 Changed 10 years ago by marchal

Resolution: fixed
Status: newclosed

(In [2313]) Deactivated x64. This closes #172.

comment:9 Changed 10 years ago by Matthäus Wander

Milestone: CrypTool 2.0 RELEASE
Note: See TracTickets for help on using tickets.