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
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.
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
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
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,
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
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,
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
30 matches
Mail list logo
