On Fri, 16 May 2008 11:21:39 -0400, "inhahe"
<[EMAIL PROTECTED]> wrote:
> They say that the C++ optimizer can usually optimize
> better than a person coding in assembler by hand can,
> but I just can't believe that, at least for me,
> because when I code in assembler,
if one hand compiles C++
Also, from the gcc manpage, apparently 387 is the default when
compiling for 32 bit architectures, and using sse instructions is
default on x86-64 architectures, but you can use -march=(some
architecture with simd instructions), -msse, -msse2, -msse3, or
-mfpmath=(one of 387, sse, or sse,387) to g
On Fri, 16 May 2008 10:13:04 -0400, inhahe wrote:
> Can anyone give me pointers/instructions/a template for writing a Python
> extension in assembly (or better, HLA)?
Look up pygame sources. They have some hot inline MMX stuff.
I experimented with this rescently and I must admit that it's etremel
On Fri, May 16, 2008 at 2:08 PM, inhahe <[EMAIL PROTECTED]> wrote:
>
> "Dan Upton" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>
>>
>> On Fri, May 16, 2008 at 1:27 PM, Mensanator <[EMAIL PROTECTED]> wrote:
>>>
>>> Why wouldn't the compilers support it? It's part of the x86
>>> a
"Dan Upton" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> On Fri, May 16, 2008 at 1:27 PM, Mensanator <[EMAIL PROTECTED]> wrote:
>>
>> Why wouldn't the compilers support it? It's part of the x86
>> architexture,
>> isn't it?
>
> Yeah, but I don't know if it uses it by default,
On May 16, 12:24 pm, "inhahe" <[EMAIL PROTECTED]> wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote in messagenews:[EMAIL PROTECTED]
>
>
>
> > 2. Once the code is functioning, benchmark it and find the
> > bottlenecks. Replace the problem methods with a C extension. Refactor
> > (and check yo
>> 3. If it is still slow, embed some assembler where it is slowing down.
>>
>
> I won't know if the assembler is faster until I embed it, and if I'm going
> to do that I might as well use it.
> Although it's true I'd only have to embed it for one system to see (more or
> less).
>
Regardless of w
On May 16, 11:24 am, "inhahe" <[EMAIL PROTECTED]> wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote in messagenews:[EMAIL PROTECTED]
>
>
>
> > 2. Once the code is functioning, benchmark it and find the
> > bottlenecks. Replace the problem methods with a C extension. Refactor
> > (and check yo
>
> yeah I don't know much about that, I was figuring perhaps I could limit the
> assembler parts / methodology to something I could write generically
> enough.. and if all else fails write for the other OS's or only support
> windows. also I think I should be using SIMD of some sort, and I'm no
>
> yeah I don't know much about that, I was figuring perhaps I could limit
> the
> assembler parts / methodology to something I could write generically
> enough.. and if all else fails write for the other OS's or only support
> windows. also I think I should be using SIMD of some sort, and I'm
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> 2. Once the code is functioning, benchmark it and find the
> bottlenecks. Replace the problem methods with a C extension. Refactor
> (and check your unit tests again) if needed to break out the problem
> areas in
inhahe schrieb:
I like to learn what I need, but I have done assembly before, I wrote a
terminal program in assembly for example, with ansi and avatar support. I'm
just not fluent in much other than the language itself, per se.
Perhaps C would be as fast as my asm would, but C would not allow
I like to learn what I need, but I have done assembly before, I wrote a
terminal program in assembly for example, with ansi and avatar support. I'm
just not fluent in much other than the language itself, per se.
Perhaps C would be as fast as my asm would, but C would not allow me to use
SIMD,
On Fri, 16 May 2008 11:21:39 -0400
"inhahe" <[EMAIL PROTECTED]> wrote:
> You could be right, but here are my reasons.
>
> I need to make something that's very CPU-intensive and as fast as possible.
> The faster, the better, and if it's not fast enough it won't even work.
>
> They say that the C+
inhahe schrieb:
Well the problem is that I'm actually not an assembler guru, so I don't know
how to implement a dll in asm or use a c calling convention, although I'm
sure those instructions are available on the web. I was just afraid of
trying to learn that AND making python-specific extensio
You could be right, but here are my reasons.
I need to make something that's very CPU-intensive and as fast as possible.
The faster, the better, and if it's not fast enough it won't even work.
They say that the C++ optimizer can usually optimize better than a person
coding in assembler by hand
On Fri, 16 May 2008 10:13:04 -0400
"inhahe" <[EMAIL PROTECTED]> wrote:
> Can anyone give me pointers/instructions/a template for writing a Python
> extension in assembly (or better, HLA)?
I am trying to imagine the requirements document for your project.
- Must be error prone and hard to debug
Well the problem is that I'm actually not an assembler guru, so I don't know
how to implement a dll in asm or use a c calling convention, although I'm
sure those instructions are available on the web. I was just afraid of
trying to learn that AND making python-specific extensions at the same ti
inhahe schrieb:
Can anyone give me pointers/instructions/a template for writing a Python
extension in assembly (or better, HLA)?
You could write a C-extension and embed assembly. See the docs for how
to write one. If you know how to implement a C-callingconvention-based
shared library in asse
Can anyone give me pointers/instructions/a template for writing a Python
extension in assembly (or better, HLA)?
--
http://mail.python.org/mailman/listinfo/python-list
20 matches
Mail list logo
