Re: Quickest way to list content of directory(s)
On Fri, 2007-02-16 at 11:35 +1100, Amos Shapira wrote: On 16/02/07, Dotan Cohen [EMAIL PROTECTED] wrote: On 15/02/07, Shachar Shemesh [EMAIL PROTECTED] wrote: Gilboa Davara wrote: BTW, certain operations (atomic operations/counters/etc) -require- asm code. In an age where GCC, probably the least optimizing compiler among all popular compilers... If gcc is so bad, can one use a different compiler on, say, an FC6 box? I'm not computer expert, but I'd like the programs that I do compile to at least run as best they could. There is a multitude of commercial compilers. Last time I heard, Intel's was considered the best or close to the best (it's their code that made Microsoft's compiler so good). Last time I checked the Intel C compiler generated code either use slow-code-paths on AMD cores, or failed completely. (Same goes for the rest of the Intel support packages [vtune, etc]). As such, it is pretty useless for multi-platform work. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Fri, 2007-02-16 at 18:43 +0200, Peter wrote: On Fri, 16 Feb 2007, Gilboa Davara wrote: On Thu, 2007-02-15 at 19:23 +0200, Peter wrote: On Thu, 15 Feb 2007, Gilboa Davara wrote: Small example. About two years ago I go bored, and decided to implement binary trees in (x86) Assembly. The end result was between 2-10 times faster then GCC (-O2/-O3) generated code. (Depending the size of the tree) The main reason being the lack of a 3 way comparison in C. (above/below/equal) And assembly lacks it too. !!!? cmp $eax,$ebx jb label_below ja label_above equal code Each jump is equivalent with a cache line flush. (Before I begin, my code targets x86_64 [AMD Opteron, Xeon 5xxx] and i386 [P4 Xeon] - nothing else.) - I'm talking about a short (+127/-128) jumps. - As far as I remember: AMD Opteron's L1I cache line size is 64b. P4/Xeon is 128b. Core2 is 64b. - Now, both the AMD and Core2 use aggressive pre-fetching that will usually result in multiple adjacent instruction cache lines. In short, It is very likely that as long as you keep your in-line assembly code -small-, you will most fit your code nicely inside the L1 I cache. But in C you can get creative with compound statements: int x,y; register int t; (t = x - y) (((t 0) below()) || above()) || equal(); .. Which will only work if the below/above/equal are made of short statements which is a very problematic pre-requisite. inline int below(your,optional,arguments); will work fine. So will: #define below(a,b,c) (z=a+b+c) Been there, done that. As I said, under both Windows and Linux the asm code yielded (much) better performance. In my case I needed to store some additional information in each leaf - making each step a compound statement by itself. (which in-turn, rendered your compound less effective) Don't be so sure about that. A compound statement can be optimized very well. .. Which will make is as readable as the asm code - or far worse... which wastes 1 register variable. Still, there is no guarantee that this generates faster code than an optimizing compiler (and gcc is not known among the best optimizing compilers). Rewriting above using binary operators and masks may be even faster. The same code was also tested under Visual Studio 2K3 and showed the same results. The assembly code was considerably faster then the VS generate binary. Assembly is not portable and it is a *** to debug. No argument there. (Though if you make your compound code complex enough, it'll make the asm code far more debug-able) Yes, you can make it run faster. It's fun for the 1st few days, after that you need to change something or port it to a NSLU2 and things stop being nice very fast. Especially if someone else needs to compile your code. As I said above, I usually use -small- (20 lines) blocks of in-line assembly code. Other then that, I'm fanatical about documentation. (Mostly because I have a very small brain and it takes me 5 minutes to forget why I trashed rax) Atomic code execution should not require assembly because segment locking can be done using C (even if that C is inline assembly for some applications). A. I -was- talking about in-line assembly. B. How can I implement lock btX/inc/dec/sub/add in pure C? (Let alone using the resulting flags. [setXX]) BTW, another valid excuse to using assembly (at least in register-barren-world-known-as-i386) is the ability to trash the base pointer. (every register count.) Again, why are you assuming x86 assembly is the target ? It could be ARM or MIPS or PPC. If I'm writing multi-platform code, I'll keep in-line assembly to the minimum. (or none) Contrary to popular belief, I'm not that mad ;) Optimizing x86 makes sense for extreme driver writing, kernel code and such. But it pays my mortgage ;) Otherwise it makes little sense on a platform that doubles its MIPS speed every 2 years. lock exists only on x86 and it exists because x86 is a brainf***d architecture that allows 'long instructions' (once upon a time known as microcode) to be interrupted in the middle. I assure you that this is a very unique feature among CPUs. True. But my target is i386/x86_64. (With the rare SPARC/POWER from time to time) Think about it, it's the only popular CPU that can be proud of being theoretically able to throw an EINTR *inside* a machine code instruction. Modifying BP + small mistake = crash. Oops. Naaah. Stack frame? who needs it ;) Seriously, the IA32 is brain-dead - no arguments there. But this brain-dead architecture managed to capture most of the computer market - and unlike Windows, it does have technical merits. (E.g. IA64 vs. IA32). My favorite architecture was the Digital Alpha, but it's water under the bridge now... Peter - Gilboa = To unsubscribe,
Re: Quickest way to list content of directory(s)
On Fri, Feb 16, 2007 at 11:35:27AM +1100, Amos Shapira wrote: There is a multitude of commercial compilers. Last time I heard, Intel's was considered the best or close to the best (it's their code that made Microsoft's compiler so good). However, I've read in the past that the Intel compiler got caught purposefully emitting code that is crippled on AMD processors. A quick Google search brings up: http://www.swallowtail.org/naughty-intel.html . -- Lionel = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Fri, 16 Feb 2007, Gilboa Davara wrote: On Thu, 2007-02-15 at 19:23 +0200, Peter wrote: On Thu, 15 Feb 2007, Gilboa Davara wrote: Small example. About two years ago I go bored, and decided to implement binary trees in (x86) Assembly. The end result was between 2-10 times faster then GCC (-O2/-O3) generated code. (Depending the size of the tree) The main reason being the lack of a 3 way comparison in C. (above/below/equal) And assembly lacks it too. !!!? cmp $eax,$ebx jb label_below ja label_above equal code Each jump is equivalent with a cache line flush. But in C you can get creative with compound statements: int x,y; register int t; (t = x - y) (((t 0) below()) || above()) || equal(); .. Which will only work if the below/above/equal are made of short statements which is a very problematic pre-requisite. inline int below(your,optional,arguments); will work fine. So will: #define below(a,b,c) (z=a+b+c) In my case I needed to store some additional information in each leaf - making each step a compound statement by itself. (which in-turn, rendered your compound less effective) Don't be so sure about that. A compound statement can be optimized very well. which wastes 1 register variable. Still, there is no guarantee that this generates faster code than an optimizing compiler (and gcc is not known among the best optimizing compilers). Rewriting above using binary operators and masks may be even faster. The same code was also tested under Visual Studio 2K3 and showed the same results. The assembly code was considerably faster then the VS generate binary. Assembly is not portable and it is a *** to debug. Yes, you can make it run faster. It's fun for the 1st few days, after that you need to change something or port it to a NSLU2 and things stop being nice very fast. Especially if someone else needs to compile your code. Atomic code execution should not require assembly because segment locking can be done using C (even if that C is inline assembly for some applications). A. I -was- talking about in-line assembly. B. How can I implement lock btX/inc/dec/sub/add in pure C? (Let alone using the resulting flags. [setXX]) BTW, another valid excuse to using assembly (at least in register-barren-world-known-as-i386) is the ability to trash the base pointer. (every register count.) Again, why are you assuming x86 assembly is the target ? It could be ARM or MIPS or PPC. Optimizing x86 makes sense for extreme driver writing, kernel code and such. Otherwise it makes little sense on a platform that doubles its MIPS speed every 2 years. lock exists only on x86 and it exists because x86 is a brainf***d architecture that allows 'long instructions' (once upon a time known as microcode) to be interrupted in the middle. I assure you that this is a very unique feature among CPUs. Think about it, it's the only popular CPU that can be proud of being theoretically able to throw an EINTR *inside* a machine code instruction. Modifying BP + small mistake = crash. Oops. Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Wed, 2007-02-14 at 10:38 +0200, Peter wrote: On Wed, 14 Feb 2007, Geoffrey S. Mendelson wrote: On Wed, Feb 14, 2007 at 08:18:16AM +0200, Shachar Shemesh wrote: Just for the record, it is not at all clear that, on modern CPUs, code you write in machine code (or even Assembly) will, in fact, run faster. The compiler can be quite good at opimizing your code for machine language expression, often much better than you would be. However, a good assembly langunage programer can write code the is leaner and meaner than a compiler generates. In practical terms, a good C programmer can often write code that is close, and parallel processing CPUs where the order of instructions is critical a good compiler can outdo an assembly language programmer. HOW do you write 'lean and mean' assembly for a quad core board with AMD or Pentium stepping (to be chosen at runtime) ? Peter Small example. About two years ago I go bored, and decided to implement binary trees in (x86) Assembly. The end result was between 2-10 times faster then GCC (-O2/-O3) generated code. (Depending the size of the tree) The main reason being the lack of a 3 way comparison in C. (above/below/equal) Granted, the size of the asm code was ~10 times the comparable C code, but in certain cases it is well worth. it. BTW, certain operations (atomic operations/counters/etc) -require- asm code. - Gilboa = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
Gilboa Davara wrote: BTW, certain operations (atomic operations/counters/etc) -require- asm code. In an age where GCC, probably the least optimizing compiler among all popular compilers, is able to unroll loops and submit them, in parallel, to a vector processor (such as the MMX and its successors), I highly doubt that the above statement is true. I will also point out that some atomic operations are, actually, old legacy from the 8080 and 8086 days, and actually perform *slower* than their multi-instruction counter parts (the command loop is one example that comes to mind). - Gilboa Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Thu, Feb 15, 2007 at 04:06:42PM +0200, Shachar Shemesh wrote: BTW, certain operations (atomic operations/counters/etc) -require- asm code. In an age where GCC, probably the least optimizing compiler among all popular compilers, is able to unroll loops and submit them, in parallel, to a vector processor (such as the MMX and its successors), I highly doubt that the above statement is true. I will also point out that some atomic operations are, actually, old legacy from the 8080 and 8086 days, and actually perform *slower* than their multi-instruction counter parts (the command loop is one example that comes to mind). Um, he was talking about operations like test-and-set or fetch-and-add. Even on architectures where they can be implemented purely in C, such implementations come at the cost of both performance and robustness. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Thu, 15 Feb 2007, Gilboa Davara wrote: Small example. About two years ago I go bored, and decided to implement binary trees in (x86) Assembly. The end result was between 2-10 times faster then GCC (-O2/-O3) generated code. (Depending the size of the tree) The main reason being the lack of a 3 way comparison in C. (above/below/equal) And assembly lacks it too. But in C you can get creative with compound statements: int x,y; register int t; (t = x - y) (((t 0) below()) || above()) || equal(); which wastes 1 register variable. Still, there is no guarantee that this generates faster code than an optimizing compiler (and gcc is not known among the best optimizing compilers). Rewriting above using binary operators and masks may be even faster. Atomic code execution should not require assembly because segment locking can be done using C (even if that C is inline assembly for some applications). Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On 16/02/07, Peter [EMAIL PROTECTED] wrote: Atomic code execution should not require assembly because segment locking can be done using C (even if that C is inline assembly for some applications). And how would you implement the lock on the segment? (assuming I guess correctly what you mean by segment locking, the closest I found was related to ELF file segments and POSIX file segment locking). --Amos
Re: Quickest way to list content of directory(s)
On Fri, 16 Feb 2007, Amos Shapira wrote: On 16/02/07, Peter [EMAIL PROTECTED] wrote: Atomic code execution should not require assembly because segment locking can be done using C (even if that C is inline assembly for some applications). And how would you implement the lock on the segment? (assuming I guess correctly what you mean by segment locking, the closest I found was related to ELF file segments and POSIX file segment locking). By segment I mean the relevant variables of the process. Atomic code execution cannot be guaranteed at user level in a premptive multitasking system. However the system guarantees thread privacy. The only way to make things 'atomic' it to run the process with root privileges and switch the sheduler to SCHED_RR and assign it a high priority. Even so hw interrupts will interrupt it. So only kernel mode code can be 'atomic'. That or realtime extensions (which are equivalent to SCHED_RR in kernel mode). Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Thu, 2007-02-15 at 19:23 +0200, Peter wrote: On Thu, 15 Feb 2007, Gilboa Davara wrote: Small example. About two years ago I go bored, and decided to implement binary trees in (x86) Assembly. The end result was between 2-10 times faster then GCC (-O2/-O3) generated code. (Depending the size of the tree) The main reason being the lack of a 3 way comparison in C. (above/below/equal) And assembly lacks it too. !!!? cmp $eax,$ebx jb label_below ja label_above equal code But in C you can get creative with compound statements: int x,y; register int t; (t = x - y) (((t 0) below()) || above()) || equal(); .. Which will only work if the below/above/equal are made of short statements which is a very problematic pre-requisite. In my case I needed to store some additional information in each leaf - making each step a compound statement by itself. (which in-turn, rendered your compound less effective) which wastes 1 register variable. Still, there is no guarantee that this generates faster code than an optimizing compiler (and gcc is not known among the best optimizing compilers). Rewriting above using binary operators and masks may be even faster. The same code was also tested under Visual Studio 2K3 and showed the same results. The assembly code was considerably faster then the VS generate binary. Atomic code execution should not require assembly because segment locking can be done using C (even if that C is inline assembly for some applications). A. I -was- talking about in-line assembly. B. How can I implement lock btX/inc/dec/sub/add in pure C? (Let alone using the resulting flags. [setXX]) BTW, another valid excuse to using assembly (at least in register-barren-world-known-as-i386) is the ability to trash the base pointer. (every register count.) - Gilboa = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On 15/02/07, Shachar Shemesh [EMAIL PROTECTED] wrote: Gilboa Davara wrote: BTW, certain operations (atomic operations/counters/etc) -require- asm code. In an age where GCC, probably the least optimizing compiler among all popular compilers... If gcc is so bad, can one use a different compiler on, say, an FC6 box? I'm not computer expert, but I'd like the programs that I do compile to at least run as best they could. Dotan Cohen http://lyricslist.com/lyrics/lyrics/49/16/ac-dc/ballbreaker.html http://what-is-what.com/what_is/skype.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On 16/02/07, Dotan Cohen [EMAIL PROTECTED] wrote: On 15/02/07, Shachar Shemesh [EMAIL PROTECTED] wrote: Gilboa Davara wrote: BTW, certain operations (atomic operations/counters/etc) -require- asm code. In an age where GCC, probably the least optimizing compiler among all popular compilers... If gcc is so bad, can one use a different compiler on, say, an FC6 box? I'm not computer expert, but I'd like the programs that I do compile to at least run as best they could. There is a multitude of commercial compilers. Last time I heard, Intel's was considered the best or close to the best (it's their code that made Microsoft's compiler so good). thefreecountry.com lists a few free C/C++ compilers, including a free version of the Intel compiler for Linux (for non-commercial use), in http://www.thefreecountry.com/compilers/cpp.shtml --Amos
Re: Quickest way to list content of directory(s)
On Wed, 14 Feb 2007, Geoffrey S. Mendelson wrote: On Wed, Feb 14, 2007 at 08:18:16AM +0200, Shachar Shemesh wrote: Just for the record, it is not at all clear that, on modern CPUs, code you write in machine code (or even Assembly) will, in fact, run faster. The compiler can be quite good at opimizing your code for machine language expression, often much better than you would be. However, a good assembly langunage programer can write code the is leaner and meaner than a compiler generates. In practical terms, a good C programmer can often write code that is close, and parallel processing CPUs where the order of instructions is critical a good compiler can outdo an assembly language programmer. HOW do you write 'lean and mean' assembly for a quad core board with AMD or Pentium stepping (to be chosen at runtime) ? Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Mon, 12 Feb 2007 20:21:46 Peter wrote: Is there some utility that can do this very simple search efficiently? Why not use a find predicate for that? Why not write a COBOL application that uses a FORTRAN subroutine to do that ? Actually (and I'm speaking with a LOT of experience) a COBOL program (with or without FORTRAN or C subs) runs at exactly same speed as a C program. BTW, you can call systemcall (like readdir()) directly from COBOL, you don't need any wrapping subroutines. You can try it with the free (and incomplete) GNU tiny COBOL (see: http://tinycobol.org/ ) or with an old (one that compiles to standalone program) MicroFucos COBOL. Ehud. -- Ehud Karni Tel: +972-3-7966-561 /\ Mivtach - Simon Fax: +972-3-7966-667 \ / ASCII Ribbon Campaign Insurance agencies (USA) voice mail and X Against HTML Mail http://www.mvs.co.il FAX: 1-815-5509341 / \ GnuPG: 98EA398D http://www.keyserver.net/Better Safe Than Sorry = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Tue, 13 Feb 2007, Ehud Karni wrote: On Mon, 12 Feb 2007 20:21:46 Peter wrote: Why not write a COBOL application that uses a FORTRAN subroutine to do that ? Actually (and I'm speaking with a LOT of experience) a COBOL program (with or without FORTRAN or C subs) runs at exactly same speed as a C program. BTW, you can call systemcall (like readdir()) directly from COBOL, you don't need any wrapping subroutines. You can try it with the free (and incomplete) GNU tiny COBOL (see: http://tinycobol.org/ ) or with an old (one that compiles to standalone program) MicroFucos COBOL. Damn I forgot the smiley again. I promise it won't happen again. Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On 12/02/07, Peter [EMAIL PROTECTED] wrote: Why not write a COBOL application that uses a FORTRAN subroutine to do that ? He wants it to run fast. Write it in machine code! Dotan Cohen http://lyricslist.com/lyrics/artist_albums/643/talib_kweli.html http://what-is-what.com/what_is/quicktime.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
To be q... fastest ... use cache! locate -r $PWD/.*/blablabla$ or locate blablabla | grep $PWD On 2/13/07, Dotan Cohen [EMAIL PROTECTED] wrote: On 12/02/07, Peter [EMAIL PROTECTED] wrote: Why not write a COBOL application that uses a FORTRAN subroutine to do that ? He wants it to run fast. Write it in machine code! Dotan Cohen http://lyricslist.com/lyrics/artist_albums/643/talib_kweli.html http://what-is-what.com/what_is/quicktime.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- Constantine Shulyupin Embedded Linux Consultant 054-4234440 http://linuxdriver.co.il/ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
He wants it to run fast. Write it in machine code! Just for the record, it is not at all clear that, on modern CPUs, code you write in machine code (or even Assembly) will, in fact, run faster. The compiler can be quite good at opimizing your code for machine language expression, often much better than you would be. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Wed, Feb 14, 2007 at 08:18:16AM +0200, Shachar Shemesh wrote: Just for the record, it is not at all clear that, on modern CPUs, code you write in machine code (or even Assembly) will, in fact, run faster. The compiler can be quite good at opimizing your code for machine language expression, often much better than you would be. However, a good assembly langunage programer can write code the is leaner and meaner than a compiler generates. In practical terms, a good C programmer can often write code that is close, and parallel processing CPUs where the order of instructions is critical a good compiler can outdo an assembly language programmer. I've kept out of that part of CPU design for a long time, I don't know if anything found on a desktop does it. I think the P4, PPC, and current SPARC chips do, but I would not bet on all of them. It's not new technology, Control Data had it in around 1970. Their chief design engineer was Seymor Cray, who later became famous on his own. It also depends upon the complexity of the intruction set. CISC computers are easy to program in assembly language and get better code, RISC chips become harder as many functions can not be done in machine code and have to be combinations of instructions. Then you are dependent upon how good your skill is at combining instructions or that of the author of your macro library. From my experience good programing technique and logic are far better at producing code effiency than writing in a specific language. I've seen many cases where the order in which you do things effects the preformance more than the languguage they were written in. Geoff. -- Geoffrey S. Mendelson, Jerusalem, Israel [EMAIL PROTECTED] N3OWJ/4X1GM IL Voice: (07)-7424-1667 Fax ONLY: 972-2-648-1443 U.S. Voice: 1-215-821-1838 Visit my 'blog at http://geoffstechno.livejournal.com/ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Monday 12 February 2007, Maxim Veksler wrote: Hi, Someone at work told me that doing du -a DIR|grep FILE is faster then find DIR|grep FILE. I've measured, it doesn't looks quite so. It did OTOH got me wondering what's the quickest way to answer if file existed in a hierarchy of directories. Assuming I'm not interested in any information besides the answer if file existing or not. I would only need to access the directory listing and not the inode of each file, right? Is there some utility that can do this very simple search efficiently? Why not use a find predicate for that? shlomi:~/progs/perl/cpan$ find . -name Ack.pm -print -quit /ack/trunk/Ack.pm shlomi:~/progs/perl/cpan$ find . -name Floooble.pong -print -quit shlomi:~/progs/perl/cpan$ Instead of -name Ack.pm you can use a different set of predicates to pinpoint your file, including -exec which allows you to run a different program. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Mon, 2007-02-12 at 15:56 +0200, Maxim Veksler wrote: Hi, Someone at work told me that doing du -a DIR|grep FILE is faster then find DIR|grep FILE. I've measured, it doesn't looks quite so. It did OTOH got me wondering what's the quickest way to answer if file existed in a hierarchy of directories. Assuming I'm not interested in any information besides the answer if file existing or not. I would only need to access the directory listing and not the inode of each file, right? Is there some utility that can do this very simple search efficiently? What about $ file -name FILE ? - Gilboa = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
Hi, Use shell globbing, like `echo *' Gilboa Davara wrote: On Mon, 2007-02-12 at 15:56 +0200, Maxim Veksler wrote: Hi, Someone at work told me that doing du -a DIR|grep FILE is faster then find DIR|grep FILE. I've measured, it doesn't looks quite so. It did OTOH got me wondering what's the quickest way to answer if file existed in a hierarchy of directories. Assuming I'm not interested in any information besides the answer if file existing or not. I would only need to access the directory listing and not the inode of each file, right? Is there some utility that can do this very simple search efficiently? What about $ file -name FILE ? - Gilboa = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- Moshe Gorohovsky A6 CC A7 E1 C2 BD 8C 1B 30 8E A4 C3 4C 09 88 47 Tk Open Systems Ltd. --- - tel: +972.2.679.5364, http://www.tkos.co.il - = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Mon, 12 Feb 2007, Shlomi Fish wrote: On Monday 12 February 2007, Maxim Veksler wrote: Hi, Someone at work told me that doing du -a DIR|grep FILE is faster then find DIR|grep FILE. I've measured, it doesn't looks quite so. It did OTOH got me wondering what's the quickest way to answer if file existed in a hierarchy of directories. Assuming I'm not interested in any information besides the answer if file existing or not. I would only need to access the directory listing and not the inode of each file, right? Is there some utility that can do this very simple search efficiently? Why not use a find predicate for that? Why not write a COBOL application that uses a FORTRAN subroutine to do that ? Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Mon, 12 Feb 2007, Maxim Veksler wrote: Hi, Someone at work told me that doing du -a DIR|grep FILE is faster then find DIR|grep FILE. I've measured, it doesn't looks quite so. It did OTOH got me wondering what's the quickest way to answer if file existed in a hierarchy of directories. locate FILE You can alias locate to actually use grep which allows using regexps for finding things in locate output directly. E.g. in my case this is set to: #!/bin/sh /usr/bin/locate.orig /|grep -E $* This can be made nicer but it's good enough. Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On 2/12/07, Shlomi Fish [EMAIL PROTECTED] wrote: On Monday 12 February 2007, Maxim Veksler wrote: Hi, Someone at work told me that doing du -a DIR|grep FILE is faster then find DIR|grep FILE. I've measured, it doesn't looks quite so. It did OTOH got me wondering what's the quickest way to answer if file existed in a hierarchy of directories. Assuming I'm not interested in any information besides the answer if file existing or not. I would only need to access the directory listing and not the inode of each file, right? Is there some utility that can do this very simple search efficiently? Why not use a find predicate for that? Well... laziness. I find find|grep be a much simpler to type then find . -name XYZ [-noleaf] -quit Regards, Shlomi Fish Maxim. -- Cheers, Maxim Veksler Free as in Freedom - Do u GNU ? = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On 2/12/07, Peter [EMAIL PROTECTED] wrote: On Mon, 12 Feb 2007, Shlomi Fish wrote: On Monday 12 February 2007, Maxim Veksler wrote: Hi, Someone at work told me that doing du -a DIR|grep FILE is faster then find DIR|grep FILE. I've measured, it doesn't looks quite so. It did OTOH got me wondering what's the quickest way to answer if file existed in a hierarchy of directories. Assuming I'm not interested in any information besides the answer if file existing or not. I would only need to access the directory listing and not the inode of each file, right? Is there some utility that can do this very simple search efficiently? Why not use a find predicate for that? Why not write a COBOL application that uses a FORTRAN subroutine to do that ? Peter Hmmm, OK. Please CC me on your first beta announcement. -- Cheers, Maxim Veksler Free as in Freedom - Do u GNU ? = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On 2/12/07, Gilboa Davara [EMAIL PROTECTED] wrote: On Mon, 2007-02-12 at 15:56 +0200, Maxim Veksler wrote: Hi, Someone at work told me that doing du -a DIR|grep FILE is faster then find DIR|grep FILE. I've measured, it doesn't looks quite so. It did OTOH got me wondering what's the quickest way to answer if file existed in a hierarchy of directories. What about $ file -name FILE ? Real situation: I've just done a major build which created 5th level directories hierarchy (debug/Main/Engine/Simple/he). Now I wish to run some quick shell test to see if anywhere inside all of this directory jungle a file named libHelpTest.a was build. Doing locate is no brainier because it's a major time waste on updatedb (this directory is there only until the next scons execution). What I'm asking is for hacks to squeeze the last bit of performance (just for fun) out of this simple file existence test. In the mean time the find|grep pair seems to be the best performer in the balance between (quick-to-type)/(fast-to-get-answer). - Gilboa Thanks, Maxim. -- Cheers, Maxim Veksler Free as in Freedom - Do u GNU ? = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Mon, Feb 12, 2007 at 09:17:59PM +0200, Maxim Veksler wrote: On 2/12/07, Gilboa Davara [EMAIL PROTECTED] wrote: On Mon, 2007-02-12 at 15:56 +0200, Maxim Veksler wrote: Hi, Someone at work told me that doing du -a DIR|grep FILE is faster then find DIR|grep FILE. I've measured, it doesn't looks quite so. It did OTOH got me wondering what's the quickest way to answer if file existed in a hierarchy of directories. What about $ file -name FILE ? Real situation: I've just done a major build which created 5th level directories hierarchy (debug/Main/Engine/Simple/he). Now I wish to run some quick shell test to see if anywhere inside all of this directory jungle a file named libHelpTest.a was build. If you're using zsh, you only need $ ls **/libHelpTest.a (I wonder whether Nadav has already sent this answer to the list...) -- Dan Kenigsberghttp://www.cs.technion.ac.il/~dankenICQ 162180901 = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On 13/02/07, Shlomi Fish [EMAIL PROTECTED] wrote: So do I sometimes. However, you specifically asked about speed and find . -name *is* faster than find | grep. And on top of that, GNU find is smart enough not to stat(2) the file if the test can be satisfied without it. A quick strace find -name ... supports this claim (see --no-leaf option for more detailed explanation). --Amos
