Skybuck's Universal Code 5 (The Native Version)

day has broken it's time to clearify some things about my

It is likely he doesn't. He is very new to the field.

Why let it be an instruction? The add process could have its own ALU section in the CPU. If the pointer is loaded first, there is time while the data section load is happening for hardware to perform the add.

If you have a machine with a 128 bit bus, you would be far better off going to a pair of 64 or 32 and 96 bit values. If you want speed, you want to use the whole bus.

There are a few operations that can be done more quickly if you can get to the MSB of the value. You may want to make your linked list a doubly linked list and keep a pointer to both ends.

Hard to talk with your mouth full?

You're an idiot.

Yes, YOU!

That is not one of the commands at your disposal to even "tell" the OS to execute.

Wrong layer, dipshit.

I assume when I tell the OS to write a file sequentially it will do it's best to do so.

If you believe this is not the case then you will have to proof that ;)

Most sectors are 512 bytes, so 64 pairs of integer and pointer will fit in it.

Worst case scenerio would be a little offset, so than 62 pairs would fit in it.

Also harddisks are pretty smart.

The chance is big they will read the next sector and cache the previous sector anyway.

So no additional seeks are needed if the data happens to spill over onto the previous or next sector.

Worst case scenerio sectors are somewhere else, which means 1 full read for the 62 pairs. 1 read for the previous spilling

However since the fill was written sequantially, the next integers and previous ones will be cached/read/write as well.

So these can all be considered full reads.

Which means the spilling onto different sectors doesn't really have to be a problem.

Which means the file fragmentation is the only real problem.

Bye, Skybuck.

Nope. If it is formatted with a file system recognized by the OS or APP, then there will be overhead on any data segment YOU wish to write to it. There has to be a "file" written, regardless of how you think you want to structure your data set.

It doesn't.

I know this not to be the case and yes I do have proof. I have the source code for the part of the OS that does this function. I have also used to tools to examine what is really on the disk.

Elsewhere in the thread, you will find my comments as to why it may not be 64 bits per entry if you want it to go fast.

You don't understand what really goes on with cached disk operations. It still drives up the processing time.

Think about the FAT based system to see why it still takes some time even if no seek is needed.

Rubbish, it's just a linked list. Anything else is an illusion created in your silly alternate reality.

Dave.

Gee, that reminds me of the FORTRAN Increment and Decrement fields as well as the contractions for their names used in LISP..

Seek(Index)

Get a clue dipshit.

How does the operating system find free sectors to write data too ?

Not that it matters much.

I have no access to the underlieing file system.

And writing one own's file system is a bit over the top don't you think ? :)

Bye, Skybuck.

You have no clue what does or does not matter.

For you, yes. Considering that you do not even know what is going on with an existing file system, I hardly think you could deal with authoring a new one.

On FAT systems, it searches the FAT table looking for a magic number that indicates a free sector. Many other systems make the free sectors into a big linked list.

It makes sense to know a little about what the OS does so that you can get the most speed out of it.

It was hardly a new idea I was suggesting, just the application of an old one to this problem.

Starting with the top bit really speeds up the computation of an unnatural-log.

Well I sure didn't learm much from you, welcome to the ban list.

Bye, Skybuck.

Nonsense.

Load whatever you need into RAM and proceed from there.

That's what RAM is for.

I have 2 and even 4 GB of RAM.

I have yet to encounter a situation where the harddisk is a real bottleneck.

Bye, Skybuck.

Simple, it writes to the first clustor that is NOT marked as used.

Since you clipped the very thing you are so unwisely calling nonsense, I'll put it back

On FAT systems, it searches the FAT table looking for a magic number that indicates a free sector. Many other systems make the free sectors into a big linked list.

It makes sense to know a little about what the OS does so that you can get the most speed out of it.

You seem to have an extremely poor understanding of the subject if you call my posting that.

To load it into RAM you need to read the disk. You wanted speed. Now you are throwing away speed hand over fist just because you didn't understand the subject. Go read up on it a bit and you will see.

I have 4GB and it isn't even close to enough. Just the raw data file for one of the things I am doing is over 2GB. Forunately, I can operate on it in sections. By carefully arranging how it is broken up, I have got the processing time to be less than 8 hours.

The nice folks at Linear. Put a 48 Bit "do it yourself" virtual memory system into LTspice. This is because the data they have is well over 4GB.

You haven't done much then.

That is not how Windows really does it. For FAT devices, it has a needlessly complex way of selecting which sector to use. The first fit method tends not to lead to fragmentation. The Windows method is carefully tuned to lead to a great deal of fragmentation. This is why you have to defrag so often on a windows box.