Is this make sence? Dynamic assembler for python
DivX
did make assembly implementation of crypting algorithm. He dynamically
generates mashine code and call that from python. Here are impressive
results http://www.daniweb.com/code/snippet216632-5.html
Is this better approach then writing extensions in c?
geremy condra
No, xor cipher is not suitable for general purpose encryption, and what do you
need the speed for? xor is almost certainly not going to be the bottleneck in
your application.
Geremy Condra
DivX
> On Sat, Jun 19, 2010 at 11:53 AM, DivX <sem.r...@gmail.com> wrote:
> > I found on the forum some discussion about crypting text and one guy
> > did make assembly implementation of crypting algorithm. He dynamically
> > generates mashine code and call that from python. Here are impressive
>
> > Is this better approach then writing extensions in c?
>
> No, xor cipher is not suitable for general purpose encryption, and what do you
> need the speed for? xor is almost certainly not going to be the bottleneck in
> your application.
>
> Geremy Condra
Just asking if this approach is good for example quicksort algoriths
or some kind of sorting algorithms, or simulations but the point is of
mixing python and assembler?
Steven D'Aprano
Ask yourself, why aren't programs written in assembly if it's so good?
(1) It's platform dependent. Do you really need a separate program for
every single hardware platform you want to run Quicksort on?
(2) Writing assembler is hard, really hard. And even harder to debug.
(3) Modern C compilers can produce better (faster, more efficient)
machine code than the best assembly code written by hand.
Honestly, this question has been resolved twenty years ago -- thirty
years ago, maybe there was still a good point in writing general purpose
code in assembly, but now? It's just showing off. Unless you're writing
hardware specific code (e.g. device drivers) it is pointless, in my
opinion.
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
Terry Reedy
You have to define 'better'. This approach requires someone to write
template assembler code, which will be machine specific. To be faster
than compiled C on a particular machine, one must be pretty good at
assemblee also.
DivX
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?
If you're interested I found a link http://www.tahir007.com/
Steven D'Aprano
> On 20 lip, 02:52, Steven D'Aprano <st...@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
DivX
cybersource.com.au> wrote:
> On Sun, 20 Jun 2010 03:19:48 -0700, DivX wrote:
> > On 20 lip, 02:52, Steven D'Aprano <st...@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...
Lie Ryan
Ever heard of JIT?
Terry Reedy
> On 06/20/10 20:57, DivX wrote:
>> On 20 lip, 12:46, Steven D'Aprano<st...@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...@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.
Of course, Psyco mixes assembly and python, which is why it was
originally (not sure now) limited to x86 machines. It does do
generically, in small chunks, behind the scenes, so the rest of us can
get the benefit without expert assembly knowledge.
>>>> I can agree with you about most of the arguments, but why he continues
>>>> to developing it.
I presume because he can and enjoys it. That sort of tinkering is what
led to Psyco.
> Ever heard of JIT?
Psyco is one form of JIT. You might enjoy reading about how it works.
Terry Jan Reedy
Rhodri James
but...
On Sun, 20 Jun 2010 01:52:15 +0100, Steven D'Aprano
<st...@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. I wrote more at a
previous job, but then the processor had instructions that could not be
expressed usefully in C, and having an FFT routine that ran like greased
lightning was important.
I would agree, though, that the only reason I can think of for wanting to
mix Python and assembler is if you are grobbling about with hardware, and
if you are doing that, Python wasn't the best place to start from.
--
Rhodri James *-* Wildebeeste Herder to the Masses
Dave Angel
> On 20 lip, 12:46, Steven D'Aprano <st...@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...@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...
>
>
against generating assembly code. That's exactly what happens every
time you write code in C. The real question is whether the code
generator your friend is writing is better than the ones written by
dozens of C gurus over the years, and better tuned to the requirements
of his particular processor. Naturally, better can be measured in
several ways.
For example, I have a processor for which no C compiler is available.
So if I were to want optimized assembler, I might need to write one
myself, or use the language for which such a code generator has been
written.
DaveA
Steven D'Aprano
> 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.
--
Steven
Steven D'Aprano
> 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
> <st...@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*
Of course, there almost certainly are special cases where the state of
the art for optimizing C compilers isn't as good as a clever human, e.g.
if you're writing for hardware where no optimizing compiler exists at
all, or some tiny CPU without all the pipelines and predictive branching
crap^W stuff they do these days.
--
Steven
Paul Rubin
> 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*
It is really true, and it's the opposite claim that would be
extraordinary. That's why compilers like gcc include pragmas for
assembler intrinsics for when you want include some inline assembly code
in your C program. gzip uses it for example, as does Gnu MP and
OpenSSL. That's why gmpy is several times faster at multi-precision
arithmetic than Python's built-in longs, that are implemented in C.
Another reason for wanting dynamic assembly code is so you can embed
staged programming in your python code. Think of how slow python
regexps are. Now imagine a regexp package that compiles your regexp
directly to assembly code instead of to some silly interpreted state
machine. Parser generators like pyparsing could similarly generate asm
code directly.
Dave Angel
"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.
DaveA
Carl Banks
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
Steven D'Aprano
> 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
DivX
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...
Dave Angel
messages were clear enough. So his acquaintance is writing an
assembler, not a code generator.
DaveA
David Cournapeau
<steve-RE...@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
>> <st...@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
MRAB
> On Mon, Jun 21, 2010 at 12:34 PM, Steven D'Aprano
> <steve-RE...@cybersource.com.au> 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
>>> <st...@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*
>
> 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 :)
>
much longer, and usually for not much gain, so it's usually a waste of
time (premature optimisation, and all that).
Stephen Hansen
> A human can write better assembly code than a compiler, but would take a
> much longer, and usually for not much gain, so it's usually a waste of
> time (premature optimisation, and all that).
When you get to the point where you're considering writing something in
assembly, its no longer "premature" -- you are clearly in a domain which
needs to process a lot of data and crunch it very efficiently.
Once you're at that point, there can be quite significant gain.
Fortunately, the vast majority of people, and situations, and programs,
don't ever get there.
And even more fortunately: very, very often when those people who *do*
get to that place, they actually can use a library which has already
done it and get those major performance gains without writing the
assembly themselves.
--
Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/
Rhodri James
<steve-RE...@cybersource.com.au> wrote:
> On Sun, 20 Jun 2010 22:45:14 +0100, Rhodri James wrote:
>
>> 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*
Fairy 'nuff. In this case it's a matter of having a simple processor and
knowing a trick or two that our in-house compiler apparently doesn't. Or
didn't, since it has improved recently. Oh, and having done this for a
decade or two :-)
But like we've been agreeing, most of the time knocking an instruction or
two out of a function isn't worth the effort.
alex23
> 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.
That has to be the most paradoxical argument I've ever heard: "when
you use assembler you have the ability to not use assembler" :)