[issue42304] [easy C] long type performance waste in 64-bit Windows build

2020-11-10 Thread Ma Lin


Ma Lin  added the comment:

> I do not think that this is suitable for newcomers because you need to have 
> deep understanding why it was written in such form at first place and what 
> will be changed if you change it.

I agree contributors need to understand code, rather than simply replace the 
type. Maybe two weeks is enough to understand the code.

> And it could negatively affect performance, especially on 32-bit platforms.

`long` type can be replaced by `ssize_t`.
`unsigned long` type can be replaced by `size_t`.
And use `PyLong_FromSize_t`/`PyLong_FromSize_t`, then there is no negative 
impact.

> I don't think that it's worth it to optimize this one.

Although the speedup is small, it's free.
I don't see it as optimization, just no more waste.

> I suggest to fix in it bpo-38252.

I forgot it in that issue, I just searched "0x80808080" in the code, it was 
missed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42304] [easy C] long type performance waste in 64-bit Windows build

2020-11-10 Thread STINNER Victor


STINNER Victor  added the comment:

> There are several different problems, such as:
> https://github.com/python/cpython/blob/v3.10.0a2/Modules/mathmodule.c#L2033

I don't think that it's worth it to optimize this one.

> In addition, `utf16_decode` also has this problem, I forgot this:
https://github.com/python/cpython/blob/v3.10.0a2/Objects/stringlib/codecs.h#L465

I suggest to fix in it bpo-38252.

--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42304] [easy C] long type performance waste in 64-bit Windows build

2020-11-10 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

I do not think that this is suitable for newcomers because you need to have 
deep understanding why it was written in such form at first place and what will 
be changed if you change it.

The code was written when unsigned long long was not standard and 64-bit 
integer type was not required in Python. PyLong_FromUnsignedLongLong could just 
not exist on the particular platform. Using long long optionally would 
complicate the code, and it was not always justified. And it could negatively 
affect performance, especially on 32-bit platforms.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42304] [easy C] long type performance waste in 64-bit Windows build

2020-11-10 Thread Ma Lin


Ma Lin  added the comment:

> What is the problem exactly?

There are several different problems, such as:
https://github.com/python/cpython/blob/v3.10.0a2/Modules/mathmodule.c#L2033

In addition, `utf16_decode` also has this problem, I forgot this:
https://github.com/python/cpython/blob/v3.10.0a2/Objects/stringlib/codecs.h#L465

Maybe these small problems are suitable for newcomer to familiarize the 
contribution process.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42304] [easy C] long type performance waste in 64-bit Windows build

2020-11-10 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

What is the problem exactly?

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42304] [easy C] long type performance waste in 64-bit Windows build

2020-11-09 Thread Ma Lin


New submission from Ma Lin :

C type `long` is 4-byte integer in 64-bit Windows build (MSVC behavior). [1]
In other compilers, `long` is 8-byte integer in 64-bit build.

This leads to a bit unnecessary performance waste, issue38252 fixed this 
problem in a situation.

Search `SIZEOF_LONG` in CPython code, there's still a few long type waste.

Novices are welcome to try contribution.

[1] https://stackoverflow.com/questions/384502

--
components: Windows
messages: 380638
nosy: malin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [easy C] long type performance waste in 64-bit Windows build
type: performance
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com