[Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes
Nikolaus Rath
Nikolaus at rath.org
Fri Jun 6 03:15:42 CEST 2014
More information about the Python-Dev mailing list
Fri Jun 6 03:15:42 CEST 2014
- Previous message: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes
- Next message: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nathaniel Smith <njs at pobox.com> writes: > Such optimizations are important enough that numpy operations always > give the option of explicitly specifying the output array (like > in-place operators but more general and with clumsier syntax). Here's > an example small-array benchmark that IIUC uses Jacobi iteration to > solve Laplace's equation. It's been written in both natural and > hand-optimized formats (compare "num_update" to "num_inplace"): > > https://yarikoptic.github.io/numpy-vbench/vb_vb_app.html#laplace-inplace > > num_inplace is totally unreadable, but because we've manually elided > temporaries, it's 10-15% faster than num_update. Does it really have to be that ugly? Shouldn't using tmp += u[2:,1:-1] tmp *= dy2 instead of np.add(tmp, u[2:,1:-1], out=tmp) np.multiply(tmp, dy2, out=tmp) give the same performance? (yes, not as nice as what you're proposing, but I'm still curious). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
- Previous message: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes
- Next message: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list