Which is more expensive ? Post: 302131762

Sponsored Content

Top Forums Programming Which is more expensive ? Post 302131762 by Perderabo on Monday 13th of August 2007 03:39:02 PM

08-13-2007

Administrator Emeritus

I would code your first snippet but compile with an optimizer. These days optimizers will unroll loops if unrolling is advantageous. That particular loop is not a real great candidate for unrolling anyway. A better candidate would be:

for(i=0; i<100; i++) A[i]=0;

Most superscalar cpus can execute:
A[i]=0;
A[i+1]=0;
A[i+2]=0;
simultaneously. How deep it can go depends on the cpu and that's why leaving unrolling to an optimizer is a good idea. The optimizer should know the target cpu. But your case involved a system call which is different. You're only saving some loop overhead.

Apparently, if you explicitly unroll a loop when it is not advantageous, most optimizers will not reroll the loop. At least this was the case circa 1998 when my copy of "High Performance Computing" was published. If you have that book, see chapter 8, "Loop Optimizations" and chapter 9, "Understanding Parallelism". This is still a great book and it's not just for Fortran programmers.

Anyway, if you are not in control of which fd's might be open, you need to to loop up to OPEN_MAX closing them. High fd's might have been opened and then setrlimit() called lower to the max fd.

Perderabo

View Public Profile for Perderabo

Find all posts by Perderabo

2 More Discussions You Might Find Interesting

1. Programming

calling pthread_self (on ubuntu), expensive?

Hi all, Is anyone aware of what operations are involved when a call to pthread_self() is made, obtaining the unique thread ID on a Ubuntu system (or even any Linux flavour)? Specifically, to retrieve the thread id, is there any locking required or atomic operations? I'm building an...

2. What is on Your Mind?

Very Expensive Running Shoes

You really should not need one third of the entire US budget to buy a pair of running shoes... even if they are name brand. What have these guys been smoking? It reminds me of the old joke... Customer: At those prices you aren't going to sell many shoes. Salesman: Ah, but all we need to do is...

LEARN ABOUT DEBIAN

bup-margin

bup-margin(1)						      General Commands Manual						     bup-margin(1)

NAME

       bup-margin - figure out your deduplication safety margin

SYNOPSIS

       bup margin [options...]

DESCRIPTION

       bup margin  iterates  through  all  objects  in	your  bup repository, calculating the largest number of prefix bits shared between any two
       entries.  This number, n, identifies the longest subset of SHA-1 you could use and still encounter a collision between your object ids.

       For example, one system that was tested had a collection of 11 million objects (70 GB), and bup margin returned 45.  That  means  a  46-bit
       hash  would be sufficient to avoid all collisions among that set of objects; each object in that repository could be uniquely identified by
       its first 46 bits.

       The number of bits needed seems to increase by about 1 or 2 for every doubling of the number of objects.  Since SHA-1 hashes have 160 bits,
       that  leaves 115 bits of margin.  Of course, because SHA-1 hashes are essentially random, it's theoretically possible to use many more bits
       with far fewer objects.

       If you're paranoid about the possibility of SHA-1 collisions, you can monitor your repository by running bup margin occasionally to see	if
       you're getting dangerously close to 160 bits.

OPTIONS

       --predict
	      Guess  the offset into each index file where a particular object will appear, and report the maximum deviation of the correct answer
	      from the guess.  This is potentially useful for tuning an interpolation search algorithm.

       --ignore-midx
	      don't use .midx files, use only .idx files.  This is only really useful when used with --predict.

EXAMPLE

	      $ bup margin
	      Reading indexes: 100.00% (1612581/1612581), done.
	      40
	      40 matching prefix bits
	      1.94 bits per doubling
	      120 bits (61.86 doublings) remaining
	      4.19338e+18 times larger is possible

	      Everyone on earth could have 625878182 data sets
	      like yours, all in one repository, and we would
	      expect 1 object collision.

	      $ bup margin --predict
	      PackIdxList: using 1 index.
	      Reading indexes: 100.00% (1612581/1612581), done.
	      915 of 1612581 (0.057%)

SEE ALSO

       bup-midx(1), bup-save(1)

BUP

       Part of the bup(1) suite.

AUTHORS

       Avery Pennarun <apenwarr@gmail.com>.

Bup unknown-															     bup-margin(1)