Mailing List Archive: assembler optimized integer overflow detection

assembler optimized integer overflow detection

Aug 23, 1999, 2:28 AM

Post #1 of 3 (181 views)

Hi there,

I wondered how Python detects integer overflows and searched the
corresponding code snippets in Python's source (Objects/intobject.c).
Because ANSI-C can't detect int overflow errors, there are very strange
workarounds for all the basic arithmetic.

I asked myself if it will be a big performance boost when someone will
re-code this routines in assembler, because an overflow can be detected very
simply by checking a processor-flag after performing the operation. Has
someone done this already? What speedup-factor would an optimization of this
kind have to the average Python code? Is it worth the work? (Let's say for
Linux/i386 machines). I'm not an Intel-assembly guy (only M68K experience),
but I think this wouldn't be too much efford for an Intel hacker, is it?

Felix
---
Dipl.-Ing. Felix von Delius Fon: 0911/4244-110
Projektleiter-IT Fax: 0911/4244-100
EBox GmbH - Agentur für neue Medien Mobil: 0172/8261220
Vordere Cramergasse 11 Email: delius@ebox.de
D-90425 Nuernberg Web: http://www.ebox.de

assembler optimized integer overflow detection [ In reply to ]

jepler at inetnebr

Aug 23, 1999, 5:11 AM

Post #2 of 3 (191 views)

Permalink

On Mon, 23 Aug 1999 11:28:06 +0200, Felix von Delius
<Delius@ebox.de> wrote:
>Hi there,
>
>I wondered how Python detects integer overflows and searched the
>corresponding code snippets in Python's source (Objects/intobject.c).
>Because ANSI-C can't detect int overflow errors, there are very strange
>workarounds for all the basic arithmetic.
>
>I asked myself if it will be a big performance boost when someone will
>re-code this routines in assembler, because an overflow can be detected very
>simply by checking a processor-flag after performing the operation. Has
>someone done this already? What speedup-factor would an optimization of this
>kind have to the average Python code? Is it worth the work? (Let's say for
>Linux/i386 machines). I'm not an Intel-assembly guy (only M68K experience),
>but I think this wouldn't be too much efford for an Intel hacker, is it?

How big does this code show up in profiling? How poor is the produced code
on your target platform?

My guess is that this isn't a big item in the profile, but I could be
wrong. If it's only, say, 5% and you speed it up by a factor of 5, then
you would gain an overall 4%, not too much. And I don't know that it is
even 5% on the programs I tend to run.

So in the absence of knowledge that this is a significant consumer of CPU
time, and in the absence of knowledge that there's a way to write the C
better, I'd say there's probably no reason to introduce non-portable
assembly code into Python.

Jeff
--
\/ http://incolor.inetnebr.com/jepler/ Jeff Epler jepler@inetnebr.com
Better to light one candle than to curse the darkness.
-- motto of the Christopher Society

assembler optimized integer overflow detection [ In reply to ]

fredrik at pythonware

Aug 23, 1999, 5:54 AM

Post #3 of 3 (178 views)

Permalink

Felix von Delius <Delius@ebox.de> wrote:
> I asked myself if it will be a big performance boost when someone will
> re-code this routines in assembler, because an overflow can be detected very
> simply by checking a processor-flag after performing the operation. Has
> someone done this already? What speedup-factor would an optimization of this
> kind have to the average Python code?

well, you could always try this:

1. run a suitable set of benchmarks (make
sure you don't use benchmarks that rely
on OverflowErrors being thrown).

2. remove the overflow checks from
Objects/intobject.c and Python/ceval.c
(search for OverflowError to find them
all), and rebuild.

3. run the same set of benchmarks again.

4. post the results.

</F>