Computing desk
< January 8	<< Dec \| January \| Feb >>	January 10 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

January 9

Multiple CPU cores vs one bigger CPU?

Is it better to have multiple CPU cores instead of just having all those transistors together in one big processor? Or is the only way to have a bigger processor by having more than 64 bits? --78.148.105.13 (talk) 01:21, 9 January 2015 (UTC)[reply]

Personally I think more cores is better, allowing you to expand the capabilities of a CPU more economically. StuRat (talk) 04:12, 9 January 2015 (UTC)[reply]

To make a computer faster, you can either put in more processors, or make the processors faster. It is sometimes possible to make a processor faster by making more sophisticated versions of units such as the adder. Also, the processor can be made faster by adding more transistors to allow for speculative execution. A method related to speculative execution is the pipeline. But at some point the designers run out of worthwhile things to do with more transistors, and the remaining alternative is more processors. Jc3s5h (talk) 04:42, 9 January 2015 (UTC)[reply]

More than 64 bits wouldn't necessarily help. '64 bits' refers to the word size of the platform, and it influences a few important things, such as how wide registers are (crudely, how big a number you can operate on) and the width of the address bus (and therefore how much physical memory the system can have). The reason 64 bits is a big improvement over 32 is that a 32 bit system can't have more than 4GB of physical RAM (and in practice more like 3.5GB) while a 64 bit system can have the square of that - about 16,000,000 TB. 3.5GB was becoming a limit; 16,000,000 TB is not yet.

The main factor in improved CPU performance for many years was increasing clock speeds (though there were other improvements, such as increased amounts of cache, pipelining, branch prediction, speculative execution etc). Once clocks hit about 3GHz, we ran out of ideas for how to increase it further. The thing limiting it is, for the most part, heat. CPUs are built of field effect transistors and when FETs switch, a small amount of charge has to pass into or out of the gate. This movement of a charge is an electric current and the material it moves through has a resistance, and so heat is dissipated (the amount being given by P=i*i*R). The amounts involved are tiny, but when you scale that up to several billion transistors switching several billion times per second, you get a significant amount of heat. The more times they switch per second, the more heat you get.

To reduce the heat, you have reduce either the amount of current or the amount of resistance, and you get more mileage out of reducing current (because of the i*i term above). The main way of doing this is to reduce the size of the transistor (as a bonus, reducing the size of everything also reduces resistance, since the charge has to travel less distance). This is still happening, but much more slowly than it had.

Since we can't figure out how to make a core do things faster, the only option left is to do more than one thing at once (ie multiple cores, though note the simplification here that some CPUs already had the ability to execute multiple instructions at once).

Which is better? The answer is, of course, that it depends on what you're doing. For most consumer use cases, two cores running at 2GHz will give you better performance than one running at 3GHz. But if you're doing certain types of simulation or software development, then maybe the 3GHz single core will be better. The ideal answer is, of course, both, and the even-better-than-that answer is to spend your money on an SSD instead, if you haven't already. GoldenRing (talk) 04:55, 9 January 2015 (UTC)[reply]

On that 16,000,000 TB limit, even if we figure disk space will double every year, it would still take over 20 years to hit that limit, so 64 bits should be good for a long time. And for storing numbers, 64 bits is plenty, too, but we could always store numbers in two registers, if we need bigger numbers/numbers with more precision. StuRat (talk) 05:52, 9 January 2015 (UTC)[reply]

64bits can address 1.6x10¹⁹ bytes - which (with framing bits, etc) is about 1.6x10²⁰ bits. Avagadro's number (the number of molecules in a mole of some material) is 6x10²³. So, for example, you're going to need around 1/1000th of a mole of material in order to have each bit stored on a single molecule. If your disk platters were coated with (for example) Ferrite (Fe₂O₃ molecular weight ~160) then a mole is 160 grams - and 1.6x10²⁰ molecules will weigh around a tenth of a gram. Since the surface of a disk platter has only about 10 to 20 nanometers of ferrite layered onto it, and with ferrite having a density of around 5g cm^-3, you'll need about half a cubic centimeter of material to store enough bytes to fill a 64 bit address space. At 20nm thickness, that would require a disk platter hundred of square meters in area! But even that is a spectacular underestimate since it's probably only the molecules on the surface of the platter that would be holding the data and we're assuming that every molecule has to store a bit.

Since we're nowhere close to being able to store a bit on a ferrite molecule, it's inconceivable that we'll never be able to make a 2D magnetic storage system capable of breaking the 64 bit limit.

So to run out of bits, we'd have to be looking at some kind of 3-dimensional storage system. Silicon chips can't really do that. The closest method I know of would be to use DNA. DNA can store 2⁷¹ bits per gram...but reading it rapidly and writing at all without corrupting it would be challenging!

2⁶⁴ bits is a lot - consider that all of the data that Facebook stores is claimed to be around 2⁵⁹ bytes...so if you wanted to host that on a single storage device, you'd comfortably be able to do that with a 64 bit address space.

Bottom line, 64 bits is "enough" by any reasonable measure for addressing a single device. However, it seems likely that humanity already has more data than that stored in computers around the world...but not on a single device. Hence we've adopted IPv6 which uses 128 bit addressing to select which computer we're talking to - and, of course, each computer can have multiple devices, each with at least 64 bits of address space. SteveBaker (talk) 17:35, 11 January 2015 (UTC)[reply]

Yes, new (3D) storage technology would be needed to use all that space, but in the 20 year time-frame I gave, new storage technologies are pretty much inevitable. As for uses for that much data, I can imagine films being all 3D, with complete voxel maps of each frame, so you can use a VR system to be a part of the film. That ought to suck down some serious storage space, if we each have a large library of such films. StuRat (talk) 18:29, 11 January 2015 (UTC)[reply]

Trustworthy sources of Windows builds of open source software?

Some of the open source software I use is hosted at Sourceforge. I've stopped downloading Windows installers from SF since reports came out in 2013 that installers hosted there were bundled with extra/unwanted software. Are there trustworthy alternative sites for Windows builds of open source software, ones that don't bundle extra stuff in the installers?

Are there ways to confirm that no unwanted extras are bundled in an installer? --134.242.92.2 (talk) 16:22, 9 January 2015 (UTC)[reply]

Do you routinely run your virus checker program against those installers? ←Baseball Bugs ^{What's up, Doc?} carrots→ 16:28, 9 January 2015 (UTC)[reply]

I experimented with 2 installers from SF. Both times the scanner didn't detect anything. It could be that there was nothing worth reporting, but it could also be that the scanner was not doing a good job. --134.242.92.2 (talk) 16:41, 9 January 2015 (UTC)[reply]

I've downloaded stuff from Sourceforge without problems, but you do have to read very carefully and decline the "extras". It's annoying that a formerly safe site is now getting a bad reputation. Dbfirs 16:57, 9 January 2015 (UTC)[reply]

Are you talking about SourceForge's DevShare program? If so, as far as I can tell, any project that uses it has a separate "direct download" link below the main download button that will take you to a clean installer. In the case of sites like download.com that add crap to other people's installers without their consent, I would recommend going to the official web site to get a clean installer. But that's unlikely to work in this case because DevShare is only enabled if the developer requests it, and revenue from it goes to the developer. Since the developer likes sideloading, you're likely to get a different sideloading installer on the official site, one that hasn't been vetted by SourceForge, and likely without the option of a clean installer. And if you go to some random download site offering the software, you'll likely get an installer with nastier bundled software, or at best the official installer. So SourceForge is probably still the safest place to download these programs in most cases, as long as you click the correct link. (Also, DevShare only affects a tiny fraction of the packages on SourceForge.)

If you want to install some software but don't entirely trust the installer, Sandboxie is useful. You can run the installer inside a sandbox, check that it didn't secretly install anything unwanted, and then either drag the main application folder out of the sandbox (which may or may not work) or else delete the sandbox and install the software for real. -- BenRG (talk) 19:29, 9 January 2015 (UTC)[reply]

Yes, SourceForge says that there are no misleading steps, and I agree with that claim, but some users seem to end up with things they don't want, so presumably they have been misled because they don't read carefully. I think it's fair to say that SourceForge will not allow any malware on its site, so virus checkers will not find anything objectionable in the downloads. I apologise to SourceForge if I implied that their poor reputation on some blogs and forums was justified and that they allow malware, but GIMP, that I downloaded from there, has now moved away from SourceForge because of the "bundleware". Dbfirs 13:02, 10 January 2015 (UTC)[reply]

A couple of months ago, I downloaded Mediainfo from SourceForge. The first thing that happened when I ran the installer was that it installed and ran something called "optimizer pro". No, I didn't click on any of those misleading "download something else" buttons, and yes, I checked carefully that there were no checkboxes with bundled software that I had to deselect. I then checked the developer's website, and the version there was bit-identical to the one on SourceForge. I then downloaded Spybot search and destroy, and checked if it detected any malware in the installer, which it did (I don't remember the details). Before posting now, I downloaded the Mediainfo installer again, and checked it with Spybot. This time, it didn't detect any malware, so the installer has been changed. I don't intend running the new installer, though. Getting rid of "optimizer" was a nuisance, and who knows what's hidden in the new installer. After this incident, I share the OP's distrust in SourceForge. --NorwegianBlue^talk 01:26, 11 January 2015 (UTC)[reply]

So SourceForge are not telling the truth about misleading steps? I must admit that I wouldn't want Optimizer Pro on my computer, and Microsoft seem to be confused about whether it is "malware" or not. It would be interesting to know what SpyBot found. Dbfirs 08:20, 11 January 2015 (UTC)[reply]

As I wrote above, in this case I carefully avoided any misleading steps, and the same installer was available for download from the developer's website. The installer contained malware. I did consider keeping the bad installer as evidence for writing a complaint, but concluded it wasn't worth the time and effort, so I deleted it and can't reproduce the exact message. It didn't identify it explicitly as "optimizer pro". I also checked the installer with Virustotal. About a third of the antivirus programs there detected malware, but gave varying names for the unwanted content. --NorwegianBlue^talk 10:18, 11 January 2015 (UTC)[reply]

There's a clear consensus that the current installer uses OpenCandy, and the OpenCandy article even mentions MediaInfo as a client. Even quite old versions use OpenCandy, so I don't know why Spybot S&D would complain a couple of months ago and not now.

Of course, this drive-by installer has nothing to do with SourceForge as such. SourceForge has merely failed to do anything about it, and I guess they don't have a policy against it. The "reports [...] in 2013 that installers hosted there were bundled with extra/unwanted software" are surely about DevShare, which was announced in mid-2013. I'm sure SourceForge hoped that projects like MediaInfo would switch to DevShare, which for all its faults is less creepy than OpenCandy. -- BenRG (talk) 21:38, 11 January 2015 (UTC)[reply]

Thanks for the clarifications, Ben. Perhaps SpyBot, like Microsoft, have relaxed their criteria on what they consider to be undesirable software. Dbfirs 22:45, 11 January 2015 (UTC)[reply]