My Assistant
|
|
|
|
|
|
|
| ||||||||||||||||
| PsychoCoder |
14 Mar, 2008 - 06:37 AM
Post
#2
|
![]() Code Or Die! ![]() Joined: 26 Jul, 2007 Posts: 5,816 |
For the record, I took the 64 bit XP off of my system because some of my hardware wouldn't work with it, like my controller card. No matter what I tried I could not get the card to install, and couldn't find 64 bit drivers for it. But when I installed 64 bit Vista I had none of these problems.
I know this has nothing to do with your question, just thought Id share my experience with XP 64 bit with you |
| Nykc |
14 Mar, 2008 - 06:44 AM
Post
#3
|
![]() DIC == Huge! ![]() Joined: 14 Sep, 2007 Posts: 2,219 |
We are heading in that direction anyways, might as well be ahead of the game. Yes you are wandering in unknown territory and you will have to adjust. I am sure you will run into some issues along the way which could become burdensome - but atleast you can look at it as a new challenge to undertake.
There are some very good concerns in this post, and I am curious of the answers myself. I know this doesn't answer your question, but your post brings up many good points. |
| thehat |
14 Mar, 2008 - 06:55 AM
Post
#4
|
![]() DIC Head ![]() Joined: 28 Feb, 2008 Posts: 216 |
The only thing that didn't work with 64bit Vista when I first installed was iTunes. No great loss.
Oh, and the flash plug in doesn't like 64bit IE, but you can run it in 32bit mode if you don't want to get a decent browser. |
| NickDMax |
14 Mar, 2008 - 07:47 AM
Post
#5
|
![]() 2B||!2B ![]() Joined: 18 Feb, 2007 Posts: 2,020 |
QUOTE ...if you don't want to get a decent browser. lolWell, I have found that most of the programs I have been worried about do actually have 64bit version. I also found a good bit of chatter about 64bit versions being slower. I have been giving this some thought -- seems counter intuitive. Then again I don't know. I really think that if this is true, it has more to do with our 8-16-32bit programming methodologies. You know I hate to say it... and I might be wrong, but I think the weight of the software world is beginning to slow down technology. 64bit programs are slower then 32bit programs -- I am willing to bet this is because we (programmers) are thinking in 32bit terms and not 64bit terms. Take for example the "64 vs 32" benchmark article: he simply recompiled 32 bit applications in 64 bit mode. Is this really optimizing for 64bit operations? Is the application taking 64bit chucks of memory and processing them, or is it still working with 32 or 16 bit chunks... I guess I will have lot to play with on the new computer... I'll keep you all updated on what I find. |
| MorphiusFaydal |
14 Mar, 2008 - 08:01 AM
Post
#6
|
|
DIC Addict ![]() Joined: 12 May, 2005 Posts: 820 |
Visual Studio should have a 64-bit Windows target. I'm not so sure about MinGW.
|
| GWatt |
14 Mar, 2008 - 08:08 AM
Post
#7
|
|
human inside ![]() Joined: 1 Dec, 2005 Posts: 1,187 |
64 bit machines are going to be slower than 32 bit machines if everything else is the same because they simply have twice as much stuff to process at the same time. However the ability to access 4 billion times the memory makes 64 bits well worth it.
|
| 1lacca |
14 Mar, 2008 - 08:10 AM
Post
#8
|
![]() code.rascal ![]() Joined: 11 Aug, 2005 Posts: 3,132 |
I think 64 bit addresses obviously take up twice as much space as 32 bit ones, so it generally halves the cache of your CPU, this means that cache intensive applications might see a decent performance hit from this alone.
However it could reduce loading overhead for memory intensive applications that can't fit all of their data into the 2G or whatever big address space at once. |
| NickDMax |
14 Mar, 2008 - 08:14 AM
Post
#9
|
![]() 2B||!2B ![]() Joined: 18 Feb, 2007 Posts: 2,020 |
QUOTE I think 64 bit addresses obviously take up twice as much space as 32 bit ones good point... but the question I have is, what makes an application cache-intensive? More to the point -- what exactly controls what gets put into cache. It would seem to me that a 64bit processor would cache the same no matter that bit-ness of the application. (this shows how much I know about caching |
| NickDMax |
14 Mar, 2008 - 08:21 AM
Post
#10
|
![]() 2B||!2B ![]() Joined: 18 Feb, 2007 Posts: 2,020 |
QUOTE 64 bit machines are going to be slower than 32 bit machines if everything else is the same because they simply have twice as much stuff to process at the same time Have to look this up, but I would imagine that the 64bit processor will still do most operations in the same number of clock cycles regardless the fact that it is reading in 64 bits rather than 32. If the processor needed to do 2 reads to load a register then there is a HUGE bottleneck. And we are talking about software executing on the same processor anyway. If there is a performance hit when using the full pipe rather than half the pipe -- the problem has to be in overhead when dealing with the full pipe. The cache observation is a good one though. |
| NickDMax |
14 Mar, 2008 - 08:38 AM
Post
#11
|
![]() 2B||!2B ![]() Joined: 18 Feb, 2007 Posts: 2,020 |
Ok my argument was this: A 32bit application running on a 64 bit processor will still need to use the same 64bit hardware architecture between processor and memory -- so it shouldn't take that much longer to load 64bit instructions/data than 32bit instructions/data.... but more than likely the good people at AMD/Intel* thought about this, and actually made an optimized mode for the current 32 bit world (esp. learning from the 16 to 32 bit jump).
But I was ignoring the bandwidth in general. I mean the memory is no faster, but has to move twice the data, and the HD is no faster but has to move/store twice the data.... etc. Sometimes I get too myopic. |
| 1lacca |
15 Mar, 2008 - 05:25 AM
Post
#12
|
![]() code.rascal ![]() Joined: 11 Aug, 2005 Posts: 3,132 |
QUOTE I think 64 bit addresses obviously take up twice as much space as 32 bit ones good point... but the question I have is, what makes an application cache-intensive? More to the point -- what exactly controls what gets put into cache. It would seem to me that a 64bit processor would cache the same no matter that bit-ness of the application. (this shows how much I know about caching I am not sure how sophisticated algorithms modern processors have, but as I've learnt from the book back in the days it is something like this: every memory access goes through the cache. So the CPU will check if the data it needs is in the cache. If it is, it gets it. If it is not, then it is serviced from the main memory (or a deeper level cache). When a data is retrieved from the main memory, it is put into the cache. If the cache is full, then something is discarded. There are a couple of strategies, amongst others are the LRU (least recently used ) , LFU (least frequently used), etc. However since modern processors have a pipeline, a look-ahead is possible, so it would modify these algorithms, since it knows what it'll need in the close future... Cache intensive application would be something that uses a small dataset, that can not fit into the registers, but it can into the cache. Maybe calculating PI or something like that, I'm not sure, but probably there are some commonly referenced things here. |
![]() ![]() ![]() |
| Time is now: 5/9/08 12:10PM |
