Fedora Files

[igachaq]

Hi, I'm an inventor and I"m working on a new supercomputer cpu replacement and I wanted to know if anyone knows how many Total Fedora Files there are, like system and program files, pretty much all of them, it would help in designing the hardware.

Thx in advance the smartest/lazy man on the planet.

[jpollard]

And what has the number of files to do with any CPU replacements?

Processors are not the problem.

Memory bandwidth and I/O bandwidth are the problem.

Number of files is irrelevant.

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

Note - that means you have to have at least 5 ports to main memory (one CPU, one I/O processor)

Lots of memory addressing (at least 64 bits). If you want a cluster/NUMA capability, then the addressing needs to incorporate a node identification in the address.

And memory access needs to support overlapping cycles to reduce latency.

NO MICROCODE - inherently slow as it limits the instruction cycle time.

All of this makes the system very very expensive.

One other thing: CPU in this context is equivalent to a single processing core.

I understand Cray got the CPU instruction cycle time down to 2.11 ns for the Cray 3.

[stevea]

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)

I expect 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.

[jpollard]

You missed the part about "very very expensive".

Seymour had VERY fast cpus, with VERY fast IPC, accomplished mostly by getting them out of cache handling, and putting the burden of speed matching in the memory modules - which made them VERY expensive.

NO cpu since has had the throughput of a cray - know any that have a memory data arrive at the cpu in one clock tick? And record computed results in the same clock tick?

The multicore units break down when they have to go to main memory as there isn't enough wires to carry all the data - so they multiplex the memory bus - which means they have to have more cache, and that interferes with IPC signals and memory access (cache misses are MUCH more expensive, and the required inter-processor signals to maintain coherent cache become MUCH more intrusive).

And for you - you forget that Seymour is no longer running Cray.

The cray systems of today are not that different from any other system - just more processors. The aggregate throughput is good though, but the single CPU throughput is much less than what the Cray 3 had. They are also a LOT less expensive.

ARM seems to have a better architecture for speed, though not the implementation.

[igachaq]

Thx for the replies, I've been designing a cpu that doesn't use any transistors, and can operate using around base 10,000 rather than binary. My original cpu design used lasers and mirrors but I came up with a new design the other day that has no components to do the actual computing, it should be able to be operate far faster than the exaflop range, probably exponentially faster. I plan on making it free available to the public, mostly so that medical and other scientific research institutions can get them free or cheaper. Plus it wil be really cheap for how fast it can be, also slower one's can be built like 100 ghz really inexpensively.
If anyone has questions I can answer or something to input, feel free to reply, but I won't disclose the exact details until I publish it, to make sure I can make the design available to the public.