Do you have a 64 bit processor?

[Talus]

I'm running a Commodore 64. That's a 64 bit, right?

[yoda313]

I'm running a Commodore 64. That's a 64 bit, right?

Wrong generation there talus

[Morse2]

Hi TheFamilyMan;

>>>...Any reason why I should consider suse64 instead?...<<<

Hmmm, if you've got both on hand, why not put 'em both on the same drive and use GRUB to choose which you want to boot into at startup? Suse uses GRUB on install and it's a handy tool (you can reconfigure it in OpenSuse's YAST to change the boot order).

Suse 10.1 is certainly a beautiful desktop environment, but it's not perfect - lack of native MP3/DVD CSS support on the initial install is a pain, and if you don't update during the install you'll find the Yast autoupdate tool to be buggy. Also, be careful if you're using ATI video along with your XGL/Compiz for the extended graphics - a number of online sources indicate some hassles to be had there. That last is hearsay, since all my current graphics cards are NVidia (mate well with NForce 4 chipsets). You shouldn't have any problems with the NVidia NForce 4's though - I've got 2 NF4's up and running with graphics maxxed in OpenSuse 10.1. According to NVidia's site their 6100/6150 Linux driver is still buggy so I'm not using it in a new slimline office machine I just tossed together. Still, even with the "pseudo NVidia" default driver it handles 2d graphics well enough for clean DVD playback off the onboard video (only using a 3500+ on that one!) as well as all the usual office tasks.

In short, OpenSuse 10.1 is easy to fall in love with but it is NOT perfect. Definitely check out Jem Matzan's "hacking opensuse 10.1" article online.

If you're new to Linux and find drive cloning to be a hassle, download Puppy 2.01. It's got a nifty little Linux disc copying script as one of the onboard tools that made it a snap to upgrade a 160GB HDD to a 320GB HDD. Much easier than writing your own with dd.

>>>...please, no wars over this...<<<

Ditto. I'm allergic to flames/flame wars too. Let's all be friends!

For those considering the 64 bit M$ options, if I held my nose hard enough to buy another M$ product after their last reactivation hassle, it would be x64 Pro. It's got the same kernel as 64 bit Enterprise Server 2003 at a fraction of the cost, and as Redwudz pointed out most of the driver issues have been worked out (still haven't found a driver for Leadtek PVR 2000 though). It's more stable than 32 bit XP Pro IME and it does seem 'snappier' on my AMD X2 4400+ than did 32 bit XP Pro FWIW. While it may lack the newer "pseudo Unix/Linux" security features (default non-admin level user) of Vista, x64 Pro is more secure than XP Pro (lack of 16 bit support pulled the rug out from under all the virii and worms that made use of legacy 16 bit process hooking to do their dirty work). As far as support goes, MOST of the updates for 64 bit Server 2003 and x64 Pro are common so unless Redmond decides to really ream their customer base I don't see it ending as soon as regular XP support. I could be wrong on that though.

So - should you go w/ a 64 bit OS? IMO absolutely! Plenty of good ones out there already and it seems a shame not to make the most of the hardware you paid for!

All the best,
Morse

[Forum Troll]

Is there a Linux version that will run on my N64?



Actually, I just bought a new laptop, HP DV8309. Has a Turion64 Mobile proc.[/img]

[akrako1]

c'mon, no Commador 64 references? BTW, what is the 64 referring to in these various devices? Video processor? Some kind of bus?

[painkiller]

If your question is serious, we are referring to 64-bit architecture of both the hardware (CPU & Motherboard) and the Operating System written and compiled to take advantage of that hardware.

Most of what's on the common folks PCs these days are either 32-bit machines (Windows 200, XP ...) or 16-bit machines (Windows 95, 98, ....).

The expression "64-bit" actually means the data bus width carrying the instructions and data of the software. Windows XP64 Pro and SUSE Linux come to my mind currently. (SUSE Linus version 10.1 is the latest and comes in two versions, 32-bit and 64-bit. As well as a free d/l for personal use - and commercial use for enterprise network applications.)

64 versus 32-bit stuff means faster operations and larger amounts of memory are easier to talk to.

As for your other reference, I wouldn't touch a "Commode-door" if you paid me.

[akrako1]

I know about 64-bit CPU's, I was wondering what the 64 refers to in Nintendo64, Commador 64, etc.

[ROF]

In nintendos case it refers to the graphics interface. In the commodore it refers to the amount of RAM(64K).

For reference 64K = 64,000Bytes, your typical PC today has 512MB which is 512,000,000Bytes. Rounded off of course. We've come a long way baby.

[Morse2]

From state of the art to nostalgia all in one thread!

Hmmm, I spent quite a bit of time on the old C64 (and it's predecessor the Vic20) back when I was learning 6502 assembly language in college. Terrific fun that! Still a good machine to work on if you want to get down to the bare metal since it's about as thoroughly documented as any piece of hardware ever was (very useful for DIYing hardware interfaces to entry level electronics projects though care must be exercised since the I/O ports are NOT 'hot swappable' - many a Complex Interface Adaptor bit the dust when electrically abused.... They even had a Z80 'expansion card' for the C64 that would let you play around with Z80 assembly (an offshoot of the 8 bit 8080 that predated the 16 bit 8086 architecture that in turn gave birth to all the other 'x86' machines out there).

ROF is right about the meaning of C64, though technically the "64" refers to 65,536 bytes (or '0000' through 'FFFF' in hexadecimal coding) of storage since a "K" is 1024 and thus '64K' is the largest number you can make up out of a 16 bit address (it takes 4 bits to make each hex digit from '0' to 'F'). This last bit causes considerable consternation among many hard drive buyers who don't realize that HDD manufacturers universally use "K" as 1000 rather than 1024 (or '0400' in hex) - leading to a smaller than advertised number when their OS reports it's size (in true 1K = 1024 numbering).

Oh well, back to the present....

If you've not got a 64 bit machine yet, get one. with the price war on between AMD and Intel, they're cheap, they're the future, and they are best served with a 64 bit OS. The only 32 bit machine I would consider for serious use would be something like a mini itx based C3 or C7 for use in a DIY embedded media device or a hyper cheap email machine.

All the best,
Morse

[ofbarea]

Since last week my Intel Pentium D 920 is running Vista x64. So far so good.

Windows recognized my HP USB scanner, pci modem (not much use for it anymore), Inten Pro 1000GT gigabit, Belking firewire 800 and Adaptec 2040AU SCSI card. I had to download Sound Blaster Audigy drivers (beta) and Epson Photo stylus R220 drivers.

I also installed updated VIA drivers for chipset and updated intel Pro set network drivers.

Even my ADSTech PYRO A/V link is working fine.

The only item I could not use was my good ATI AIW 9000 .

[yoda313]

I have an amd athlon 64 3800 2.4ghz single core processor now

Though I'm running a 32bit vista premium

[Ghozt Particlez]

I have an AMD X2 3800+ overclocked and running XP. I don't think I'll be upgrading to Vista64 for another 2-3 years, until developers know how to develop multi-threaded applications for Vista64.

From what I heard from a friend, who's a CS professor in Silicon Valley, the next few years will be a weed out period for software companies because most of their programmers aren't smart enough to develop multi-threaded applications for Vista64, unlike Mac developers who have been doing multi-threaded applications in 64 bit for eons. So don't expect 64 bit drivers, games, etc. anytime soon.

Of course, all this is speculation.

[JohnnyMalaria]

From what I heard from a friend, who's a CS professor in Silicon Valley, the next few years will be a weed out period for software companies because most of their programmers aren't smart enough to develop multi-threaded applications for Vista64, unlike Mac developers who have been doing multi-threaded applications in 64 bit for eons. So don't expect 64 bit drivers, games, etc. anytime soon.

Of course, all this is speculation.

That doesn't make sense. Writing multithreaded apps for Win64 is no different than writing them for Win32. And people have been writing multithreaded apps for Win32 much longer than they have for Mac....

Multithreaded apps on Windows aren't some new-fangled thing because of the arrival of multicore CPUs. NT flavors of Windows have been multithreaded since approx. 1991. Microsoft's compilers have supported native multithreaded apps for a long time.

[Ghozt Particlez]

From what I heard from a friend, who's a CS professor in Silicon Valley, the next few years will be a weed out period for software companies because most of their programmers aren't smart enough to develop multi-threaded applications for Vista64, unlike Mac developers who have been doing multi-threaded applications in 64 bit for eons. So don't expect 64 bit drivers, games, etc. anytime soon.

Of course, all this is speculation.

That doesn't make sense. Writing multithreaded apps for Win64 is no different than writing them for Win32. And people have been writing multithreaded apps for Win32 much longer than they have for Mac....

Multithreaded apps on Windows aren't some new-fangled thing because of the arrival of multicore CPUs. NT flavors of Windows have been multithreaded since approx. 1991. Microsoft's compilers have supported native multithreaded apps for a long time.

Actually, I don't know if it makes sense or otherwise, but I am hearing this from a good authority, and that's just his opinion and his observations from doing consulting work for top tier software companies.

I do know that 64 bit is the next logical step, and we're not even close to being there. When I think about it, encoders like HC, Procoder and CCE (basic version of the two latter encoders) aren't even multi-threaded. I have a dual core and they're not at full load when using these encoders. I even downloaded CCE SP2 trial to see if it can max out my CPU usage and it doesn't. I built a 64 bit, dual core PC in the hopes to use its dual core and 64 bit capabilities, but now, I only have a miniscule hope of ever using these features.

[JohnnyMalaria]

I can only speak to my experience with Microsoft's Visual Studio for compiling programs. The default for years has been to produce multithreaded code. But just because it is multithreaded, it doesn't mean it parallelizes well. Getting the program to perform key parts in parallel - and therefore make use of all the available CPUs - requires a somewhat different way of thinking.

In one of our apps, the heart of the code is an decoder/encoder. It is written to perform as much of the task as possibile in parallel - but much of the program has to do stuff serially. e.g., if the program is working with live video, you can't grab more than one frame at a time from the camera. In practical terms, on a dual-core system, we get about a 30% to 50% boost compared to the non-parallel version. It's also important to verify that the parallel code is faster. You can write parallel code only to discover that it performs slower than the serial version even when multiple processors are available. A good understanding of the computer's architecture, especially RAM and processor caches, is essential.

It's easy to use the buzz words "our app is multithreaded". It's easy to achieve. The harder part is to make the app perform as much of the tasks as possible in a parallel fashion. Multithreading is the means to the end. The "end" is a high degree of parallel processing. The other hurdle to developing parallel code is that you must have at least two processors to test it on. You cannot test it on a single processor system.

With 32-bit vs 64-bit, Visual Studio makes it very easy. Especially for new code. There are some simple rules to follow - and if you lapse into 32-bit thinking, the compiler will warn you that the code isn't portable. Once you've written your portable code, you simply tell the compiler which platform to generate the code for. Converting existing 32-bit code to be native 64-bit, on the other hand, can be a painstaking and time-consuming process.

Many years ago, I used to use Borland compilers. The disadvantage I found quite quickly is that non-Microsoft compilers are always playing catch-up with Microsoft in terms of native support in the compiler for the latest features of the OS.

Microsoft offer free versions of their compilers. That, coupled with the increasing number of multiple 64-bit processor systems, means that gradually you will begin to see new applications offered in 32-bit and 64-bit versions along with better support for parallel processing.

[ofbarea]

Do you have a 64 bit processor?

I have a second 64 bit procesor now. A nice DEC3000-400 (Sandpiper) with an Alpha 21064 133MHz CPU.

I just need to get an OpenVMS hobbyist license from HP. In the mean time I think I will try BSD on it.