Jump to content

Vista 64bit/Multi core support


FasterTorrent

Recommended Posts

  • 2 months later...

Still, it wouldn't actually be that difficult. I mean, it's not really "early" anymore to start doing 64-bit builds. I bought a p35 chipset, a core2, and put a new video card in it and viola! I had a fully driver supported 64bit system; it's rock-solid stable and fast as ****. I have 0 reasons to ever install or use the 32bit system at home again. The less the system has to virtualize 32bit environments, I figure, the better. Sure, it's not going to make a huge perf change. But at the same time, they're going to have to do it at one point or another. Why not just get some alpha builds started and let us have a run at it? This is, after all, all for the fun of it; we're not making airplanes here. Most of us do this because we dig new technologies; they do cool things and we like to play with them.

m0d

PS. The compile should be fairly easy. Just make sure pointers are stored to 64bit types.

PSS. Respectfully, there are advantages that some people have actually claimed don't exist. To quote "Overview of x64 Calling Conventions" from MSDN's C++ Development Center: ( http://msdn2.microsoft.com/en-us/library/ms235286(VS.80).aspx )

"Two important modifications from x86 to x64 are the 64-bit addressing capability and a flat set of 16 64-bit registers for general use. Given the expanded register set, x64 just uses the __fastcall calling convention and a RISC-based exception-handling model."

Link to comment
Share on other sites

  • 1 month later...

In the strictest traditional sense - no, uTorrent is not multi-core aware at the code level. However, uTorrent always has around 4 threads running doing various things; so unless you have more then four cores there is no real difference unless you are doing something serious like hashing multiple multi-gigabyte files.

I imagine in some future version uTorrent could offload seperate file hashings to seperate cores. Kind of more of a 2.0 thing really.

@m0d

The reason we don't support 64-bit builds at the moment is that we try to have a one-size-fits-all build.

Link to comment
Share on other sites

Of course 32bit client currently is enough for desktops. Will not be enough when 8GB of RAM will become standard on desktop. Two years or so. X64 usage will only increase with time. Question is not if, but when you switch to X64. Also, what is the right strategy to do that. Probably not switching to X64 overnight, but introducing X64 version, and after majority will switch to X64, drop 32bit.

X64 version is needed already today for servers: Windows 2003 or Windows 2008 (soon). The primary reason for X64 is very effective high performance uTorrent disk cache. Windows file cache is wrong implemented: low performance, serial process, so very blocking under higher loads.

I migrated file distribution tasks to torrents from FTP. Now running file servers distributing content via uTorrent and the biggest bottleneck are disk subsystems (at least before we totally move to flash based disks).

I would like to increase the cache size up to ~15GB (for server with 16GB RAM) or up to 30GB (32GB server), totally avoiding windows file cache. This would allow to achieve upload speeds of up to several Gbps from one server (impossible to achieve not from memory). Example: 12GB service pack is released for popular product.

Unfortunatelly I am not able to increase uTorrent disk cache size over 2GB now.

Two other notes:

1. Running seeding engine as a service would help in "file server" scenario (GUI separation). "Nice to have", not critical. More important is:

2. Magnet link support needed. It doesnt matter that DHT are different, will be enough of just uTorrent users to get torrent file in many cases, and the same magnet links will work. When links will start working we totally can replace FTP servers with better file distribution technology (send links via e-mail etc. where attachments are not welcome - magnet links will work same as FTP links today with better reliability. We can just send 2 links in e-mail to send file of any size - magnet link, and other link to utorrent.com site in case user does not have the uTorrent client yet).

Thanks to utorrent team for your hard work building the best torrent based file sharing engine and client.

Link to comment
Share on other sites

  • 3 months later...
  • 3 months later...
  • 1 month later...

your half right not so nice dreadwingknight, i am / was using utorrent 1.7.7 and just found square cube icon make 1.8 back

not multicore support if your looking for relevance, it must have been my imagination popping vista premium oem x64 over 32

thinking it was. now i notice 1,8 nicely takes over the requests from 1,7,7 but trows half as queued, so maybe it is x64 ;-S

Link to comment
Share on other sites

  • 4 months later...
  • 2 weeks later...

Is there really such a fuss going into 64-bit? Is'nt it merely a matter of checking a "64-bit" flag in the compiler settings dialogue or in the makefile.conf and voìlá, you have a 64bit version of the software?

I don't really think that there is a technical difference between 32 and 64 bit for the high level programmer. The compiler takes care of everything and automatically optimizes for the environment you set it to.

Link to comment
Share on other sites

There are plenty, such as every assumption about the size of a pointer, a lot can be affected by this; casts, struct hacks, conversion to an integer that suddenly has a size mismatch, and more

Sure a lot of it can be avoided by writing "portable" code, but more often than not it ends up being really painful and it'd make excessive use of sizeof and even charbit.. the linux guys like writing portable code - I'd rather call it painful.

And that's not going to help any if the code wasn't portable to begin with, you'd just end up porting it.

Those are not even All the problems..

It's barely worth it either, you could have a bigger cache (well duh, but do you need that?) and the hash checking and PE may use less CPU time (because of the extra registers and x86-64 CPU's always have at least SSE2 - not sure whether that is used in the 32bit build of µT)

Link to comment
Share on other sites

@g00ey: At least give software developers some credit... If it were so simple, tons of projects wouldn't have such trouble migrating to 64-bit, and no one would boast 64-bit support when it finally arrives in an application. (And C++ isn't really that high-level a programming language anyway)

Assumptions made when developing for 32-bit may not hold true when transitioning to 64-bit. 64-bit support often isn't something that comes for free unless you start the project with 64-bit support in mind -- or unless you code carefully.

http://www.autoitscript.com/forum/index.php?s=&showtopic=76114&view=findpost&p=552385

See this for the post I've most recently read on the matter (more-or-less similar to what Harold wrote, albeit much more specific).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...