From: Carl Banks on
On Jun 21, 12:00 am, Dave Angel <da...(a)ieee.org> wrote:
> Steven D'Aprano wrote:
> > On Sun, 20 Jun 2010 18:21:43 -0400, Dave Angel wrote:
>
> >> Something's intrinsically wrong with the argument made in this thread
> >> against generating assembly code.  That's exactly what happens every
> >> time you write code in C.
>
> > I don't know whether C compilers generate assembly mnemonics or direct
> > machine code, but the distinction for this argument is irrelevant.
>
> > The argument in this thread is that it's not worth the *human coder*
> > writing assembly, not that no assembly code is involved in the process
> > anywhere.
>
> But the OP said of his friend:
>
> "He dynamically generates mashine code and call that from python."
>
> I took that to mean he dynamically generated machine code, not that he hired some human to do it.

Well we know what you meant, but he did post a snippet of the code
showing handwritten assembly, from which the machine code is
dynamically generated.

Inline assembly not too useful for general purpose Python programming,
but I'm sure there's a time and place for it.

I wonder how easy it'd be to bundle a small C compiler.


Carl Banks
From: Steven D'Aprano on
On Mon, 21 Jun 2010 03:00:12 -0400, Dave Angel wrote:


> But the OP said of his friend:
>
> "He dynamically generates mashine code and call that from python."
>
> I took that to mean he dynamically generated machine code, not that he
> hired some human to do it.


Well, I suppose if his friend is a robot or alien intelligence, you could
very well be right. *wink*

Otherwise, whether his friends writes the assembly, or he hires someone
to do it, what's the difference?

(If you follow the OP's link to the code, it seems fairly clear to me
that it uses hand-written assembly code.)



--
Steven
From: DivX on
On 20 lip, 12:57, DivX <sem.r...(a)gmail.com> wrote:
> On 20 lip, 12:46, Steven D'Aprano <st...(a)REMOVE-THIS-
>
>
>
>
>
> cybersource.com.au> wrote:
> > On Sun, 20 Jun 2010 03:19:48 -0700, DivX wrote:
> > > On 20 lip, 02:52, Steven D'Aprano <st...(a)REMOVE-THIS-
> > > cybersource.com.au> wrote:
> > [...]
> > >> I think that mixing assembly and python is a gimmick of very little
> > >> practical significance. If you really need the extra performance, check
> > >> out PyPy, Cython, Pyrex and Psyco.
>
> > >> --
> > >> Steven
>
> > > I can agree with you about most of the arguments, but why he continues
> > > to developing it. What he sees and we do not see?
>
> > Why ask us? You should ask him.
>
> > --
> > Steven
>
> Be sure I will ask him, but before, I wanted to know your opinions
> about it. Hear arguments on both sides...

Where I wrote that he was my friend? But that is not the point, I send
him a mail and here is answer:

"I know that writing assembly code is hard but when you want some
simple algorithm like algorithms in image processing or in digital
signal processing you must write functions in C and then write wrapper
to call that from python because it’s slow to do all work from python.
And then if you want to support windows and Linux you will spend more
time about compiling and see if everything works correctly than on
algorithms.

Another thing is that when you have assembler now you can write some
small C compiler so that you don’t have to write assembly language.
It’s doesn’t matter if gcc will produce better code it’s enough to
achieve speed that you are satisfied and you don’t have to worry
about how to write extensions for Python.

Also many people use intrinsic functions to achieve more speed when
they need. I think programming using intrinsic functions is like using
sse instructions directly.

Best regards,

Tahir"

So, thanks people for your opinions and arguments...
From: Dave Angel on
Steven D'Aprano wrote:
> On Mon, 21 Jun 2010 03:00:12 -0400, Dave Angel wrote:
>
>
>
>> But the OP said of his friend:
>>
>> "He dynamically generates mashine code and call that from python."
>>
>> I took that to mean he dynamically generated machine code, not that he
>> hired some human to do it.
>>
>
>
> Well, I suppose if his friend is a robot or alien intelligence, you could
> very well be right. *wink*
>
> Otherwise, whether his friends writes the assembly, or he hires someone
> to do it, what's the difference?
>
> (If you follow the OP's link to the code, it seems fairly clear to me
> that it uses hand-written assembly code.)
>
>
>
My fault. I didn't follow the link. I assumed the words in all those
messages were clear enough. So his acquaintance is writing an
assembler, not a code generator.

DaveA

From: David Cournapeau on
On Mon, Jun 21, 2010 at 12:34 PM, Steven D'Aprano
<steve-REMOVE-THIS(a)cybersource.com.au> wrote:
> On Sun, 20 Jun 2010 22:45:14 +0100, Rhodri James wrote:
>
>> Mixing Python and assembler is a bizarre thing to want to do in general,
>> but...
>>
>> On Sun, 20 Jun 2010 01:52:15 +0100, Steven D'Aprano
>> <steve(a)remove-this-cybersource.com.au> wrote:
>>
>>> (3) Modern C compilers can produce better (faster, more efficient)
>>> machine code than the best assembly code written by hand.
>>
>> No.  Modern C compilers often produce very good machine code, but the
>> best hand-written assembly code will be better.  I can usually write
>> *very* marginally better code than GCC achieves at work, though 99% of
>> the time I don't because it would be a maintenance nightmare.
>
>
> Not that I don't believe you, but that is an extraordinary claim that
> would require more evidence than just "Hey, some guy on the Internet
> reckons his assembly code can regularly out-perform optimizing C
> compilers" before I will change my opinion *wink*

No, it is not extraordinary claim, I would actually think it is common
knowledge. For performance sensitive, extremely well constraints
algorithm, ASM easily beats general C compilers. Most optimized
numerical libraries rely quite heavily on ASM to get significant speed
up (Atlas, FFTW, MKL). C has actually a few majors aspects which makes
some optimizations very hard to do - things like pointer aliasing, for
example, where the compiler has to be quite pessimistic in general.

Also, the fact that current compilers can generate code which is
significantly faster than they used to a few years ago *on the exact
same C code* show that it is not that hard to beat C compilers. They
manage to do it by themselves :)

David