Originally Posted by jpollard
And what has the number of files to do with any CPU replacements?
It has a LOT to do with it if you aren't making a conventional processing system, tho' I'd imagine the code size would be a lot more inerestng than the number of files.
Processors are not the problem.
Memory bandwidth and I/O bandwidth are the problem.
Number of files is irrelevant.
If you are only considering conventional system design then you make a point, but not everyone is so stuck-in-the-mud. System architecture can address memory and I/O bandwidth readily via increased parallelism. *BUT* there are every hard IPC problems to make such distributed systems perform well - and that can involve CPU design in terms of IPC and problem distribution, not raw computation speed.
The trend has been toward a handful of cores with a single (or for servers a few) memory bus(ses) connecting DRAM to cache. Similarly we have storage (whether networked or local) with at best modest parallelism.
But we are starting to see system announcements for 100-ish core systems per board, and in these designs each chip has multiple conventional memory busses, and of course special provisions must be made for cache coherence. As always - the business of distributing work across multiple compute engines is costly in terms of IPC, and must be justified on a performance basis.
Here for example: http://www.tilera.com/products/processors
Runs Linux btw.
I don't know what the OP has in mind (nor do you) but distributing files (or other units of storage) across highly parallel systems could be used to create high performance systems (if other problems of IPC can be addressed - the hard part). A file is just a handle for data storage - the number of handles isn't usually terribly important, except it might imply a means to split up some of the work, or a limit to useful parallelism
To answer the OPs question,
A smallish Fedora install has about 50,000 files, 6400 directories, and occupies ~1GB
A decent fedora desktop install (rootfs, not user data) has ~260,000 files, ~32,000 dirs, using ~10GB
(IOW 5x larger)
the full set of fedora packages (from official repo only) might be around 600k files, and 25+GB.
---------- Post added at 07:16 AM ---------- Previous post was at 06:48 AM ----------
Originally Posted by jpollard
Seymour Cray solved the CPU issues years ago
1. eliminate cache (means no stalls to access memory)
2. main memory operating at the speed of the current L1 cache
3. 4 ports to memory for each CPU, 1- instruction input; 2-data input; 3-data input; 4- data output
4. a memory port to I/O processor operating at the same speed (or faster) as the CPU
LOL - I find it amusing that you imagine this problem was solved in the 1980s.
I've got some bad news for you sunshine - Cray has moved far-far away from that approach, and today every Cray supercomputer, just like almost every other super computer, is made massively parallel x86 or other GP archiecure parts as the compute engine. None of your suggest solution rules are followed.