Jack O'Connor added the comment:
I did reply to that point above with some baseless speculation, but now I can
back up my baseless speculation with unscientific data :)
https://gist.github.com/oconnor663/aed7016c9dbe5507510fc50faceaaa07
According to whatever `powerstat -R` measures
Jack O'Connor added the comment:
> Truncated sha512 (sha512-256) typically performs 40% faster than sha256 on
> X86_64.
Without hardware acceleration, yes. But because SHA-NI includes only SHA-1 and
SHA-256, and not SHA-512, it's no longer a level playing field. OpenSSL&#x
Jack O'Connor added the comment:
> Hardware accelerated SHAs are likely faster than blake3 single core.
Surprisingly, they're not. Here's a quick measurement on my recent ThinkPad
laptop (64 KiB of input, single-threaded, TurboBoost left on), which supports
both A
Jack O'Connor added the comment:
> maintaining a complicated build process in-tree
For what it's worth, if you have any sort of "in a perfect world" vision for
what the upstream BLAKE3 project could do to make it trivially easy for you to
integrate, I'd be ver
Jack O'Connor added the comment:
Thanks Larry! Was any of the experimental C extension code under
https://github.com/oconnor663/blake3-py/tree/master/c_impl useful to you? I was
wondering if it could be possible to copy blake3module.c from there verbatim.
The setup.py build there als
Jack O'Connor added the comment:
Yes, everything in https://github.com/BLAKE3-team/BLAKE3 and
https://github.com/oconnor663/blake3-py is public domain via CC0, and dual
licensed under Apache for good measure. Hopefully that makes it easy to use it
any
Jack O'Connor added the comment:
What's the best way for me to help with the next steps of this?
--
___
Python tracker
<https://bugs.python.o
Jack O'Connor added the comment:
Yeah by intrinsics I mean stuff like _mm256_add_epi32(). All of that stuff is
in these vendored files:
blake3_avx2.c
blake3_avx512.c
blake3_neon.c
blake3_sse2.c
blake3_sse41.c
Also to Michał's question above, I'm not necessarily oppose
Jack O'Connor added the comment:
> As a first pass I say we merge the reference C implementation.
Do you mean portable-only C code, or portable + intrinsics? If the assembly
files are out, I'd advocate for the latter. The intrinsics implementations are
nearly as fast as the
Jack O'Connor added the comment:
I was about to say the only missing feature was docstrings, but then I realized
I hadn't included releasing the GIL. I've added that and pushed an update just
now. Fingers crossed there's nothing else I've missed. I think it's
Jack O'Connor added the comment:
Ah, good idea. I've published the new C implementation as:
https://test.pypi.org/project/blake3-experimental-c/
You can install it with: pip install -i https://test.pypi.org/simple/
blake3-experimental-c
Despite the package name change, the extens
Jack O'Connor added the comment:
Update: There is now a C version of the `blake3` Python module available at
https://github.com/oconnor663/blake3-py/tree/master/c_impl. It's completely
API-compatible with the Rust version, and it passes the same test suite.
Multithreading
Jack O'Connor added the comment:
Hi Michał, no I haven't done any more work on this since my comments back in
April. If you wanted to get started on a PyPI implementation, I think that
would be fantastic. I'd be happy to collaborate over email:
oconnor...@gmail.com. The branch
Change by Jack O'Connor :
--
nosy: -oconnor663
___
Python tracker
<https://bugs.python.org/issue25782>
___
___
Python-bugs-list mailing list
Unsubscr
Jack O'Connor added the comment:
Hey Christian, yes these are new bindings, and also incomplete. See comments in
https://github.com/oconnor663/cpython/commit/dc6f6163ad9754c9ad53e9e3f3613ca3891a77ba,
but in short only x86-64 Unix is in working order. If 3.10 doesn't seem
real
Jack O'Connor added the comment:
An update a year later: I have a proof-of-concept branch that adds BLAKE3
support to hashlib: https://github.com/oconnor663/cpython/tree/blake3. That
branch is API compatible with the current master branch of
https://github.com/oconnor663/blake3-py.
Jack O'Connor added the comment:
Right, the example above is contrived to demonstrate the race and the crash.
In real life code, the good reason I know of to write code like this is to use
os.waidid(WNOWAIT) to solve the wait/kill race properly. This is what Duct has
been doing
Jack O'Connor added the comment:
Filed separately as https://bugs.python.org/issue42558.
--
___
Python tracker
<https://bugs.python.org/issue38630>
___
___
New submission from Jack O'Connor :
In Python 3.9, Popen.send_signal() was changed to call Popen.poll() internally
before signaling. (Tracking bug: https://bugs.python.org/issue38630.) This is a
best-effort check for the famous kill/wait race condition. However, because
this can now re
Jack O'Connor added the comment:
I'm late to the party, but I want to explain what's going on here in case it's
helpful to folks. The issue you're seeing here has to do with whether a child
processs has been "reaped". (Windows is different from Unix here
Jack O'Connor added the comment:
This change caused a crash in the Duct library in Python 3.9. Duct uses the
waitid(NOWAIT) strategy that Nathaniel Smith has described in this thread. With
this change, the child process is reaped by kill() in a spot we didn't expect,
and a subse
Jack O'Connor added the comment:
Ah never mind, it looks like that's covered by
https://bugs.python.org/issue3
--
___
Python tracker
<https://bugs.python.o
Jack O'Connor added the comment:
This change may have broken pyflakes on nightly Python. Is that expected or
problematic?
Error message:
"pyflakes" failed during execution due to "module 'ast' has no attribute
'AugLoad'"
Seen at: https:
Jack O'Connor added the comment:
I've just published some Python bindings for the Rust implementation on PyPI:
https://pypi.org/project/blake3
> I'm guessing Python is gonna hold off until BLAKE3 reaches 1.0.
That's very fair. The spec and test vectors are set in s
Jack O'Connor added the comment:
Version 0.2.0 of the BLAKE3 repo includes optimized assembly implementations.
These are behind the "c" Cargo feature for the `blake3` Rust crate, but
included by default for the internal bindings crate. So the easiest way to
rerun our favori
Jack O'Connor added the comment:
Version 0.1.3 of the official BLAKE3 repo includes some significant performance
improvements:
- The x86 implementations include explicit prefetch instructions, which helps
with long inputs. (commit b8c33e1)
- The C implementation now uses the same par
Jack O'Connor added the comment:
I plan to bring the C code up to speed with the Rust code this week. As part of
that, I'll probably remove comments like the one above :) Otherwise, is there
anything else we can do on our end to help
Jack O'Connor added the comment:
Ok, I've added Rust bindings to the BLAKE3 C implementation, so that I can
benchmark it in a vaguely consistent way. My laptop is an i5-8250U, which
should be very similar to yours. (Both are "Kaby Lake Refresh".) My end result
do look s
Jack O'Connor added the comment:
I'm in the middle of adding some Rust bindings to the C implementation in
github.com/BLAKE3-team/BLAKE3, so that `cargo test` and `cargo bench` can cover
both. Once that's done, I'll follow up with benchmark numbers from my laptop
(Kaby
New submission from Jack O'Connor :
See https://github.com/BLAKE2/libb2/issues/12.
All Blake2 params have to be encoded in little-endian byte order. For the two
multi-byte integer params, leaf_length and node_offset, that means that
assigning a native-endian integer to them appears to wo
Jack O'Connor added the comment:
Related: The asyncio communicate() method differs from standard subprocess in
how it treats input bytes when stdin is (probably mistakenly) not set to PIPE.
Like this:
proc = await create_subprocess_shell("sleep 5")
await proc.co
Jack O'Connor added the comment:
Thanks for the heads up, Berker, I've re-submitted the PR as
https://github.com/python/asyncio/pull/335.
--
___
Python tracker
<http://bugs.python.o
New submission from Jack O'Connor:
Setting stdin=PIPE and then calling communicate(b"") should close the child's
stdin immediately, similar to stdin=DEVNULL. Instead, communicate() treats b""
like None and leaves the child's stdin open, which makes the chil
Changes by Jack O'Connor :
--
nosy: +oconnor663
___
Python tracker
<http://bugs.python.org/issue24909>
___
___
Python-bugs-list mailing list
Unsubscr
Jack O'Connor added the comment:
Yury, can you help me understand why `hasattr("foo", "bar")` triggers the
infinite loop there, but not `print("foo")`?
--
___
Python tracker
Changes by Jack O'Connor :
--
nosy: +oconnor663
___
Python tracker
<http://bugs.python.org/issue25786>
___
___
Python-bugs-list mailing list
Unsubscr
Jack O'Connor added the comment:
Yury, do we need to handle more complicated infinite loops, where "self"
doesn't actually show up in the loop? Here's an example:
try:
raise Exception
except Exception as ex:
loop1 = Exception()
loop2 =
Changes by Jack O'Connor :
--
nosy: +oconnor663
___
Python tracker
<http://bugs.python.org/issue25781>
___
___
Python-bugs-list mailing list
Unsubscr
Jack O'Connor added the comment:
Thanks for chasing this down. Yury, can you suggest a workaround?
--
___
Python tracker
<http://bugs.python.org/is
New submission from Jack O'Connor:
The following hangs at 100% CPU on Python 3.5, though not on Python 3.4:
1) Start an asyncio coroutine with run_until_complete().
2) Inside the coroutine, enter an ExitStack using a with-statement.
3) Inside the with-statement, call ExitStack.enter_co
Jack O'Connor added the comment:
Definitely a duplicate, thanks for pointing me to the original. Should I mark
it resolved, or let someone from the project do that?
--
___
Python tracker
<http://bugs.python.org/is
New submission from Jack O'Connor:
The Windows implementation of Popen calls _make_inheritable(), which creates
inheritable copies of Popen's file descriptors. If two Popen calls happen at
the same time on different threads, these descriptors can leak to both child
processes
Jack O'Connor added the comment:
Got it, thanks for the heads up.
--
___
Python tracker
<http://bugs.python.org/issue23548>
___
___
Python-bugs-list m
Jack O'Connor added the comment:
@gvanrossum, the last two lines you suggested don't give any error, as
expected. Not sure why we're getting that error message in the toy example.
@haypo, closing the event loop explicitly works fine for me. But since you
mentioned it, I don&#x
Jack O'Connor added the comment:
`close()` fixes it; thanks for the workaround! When I throw a print statement
inside `remove_signal_handler`, it says that sig is 17 and handler is 0. 17
looks to be SIGCHLD, presumably from the little echo subprocess exiting in this
ex
New submission from Jack O'Connor:
This toy program:
import asyncio
@asyncio.coroutine
def main():
p = yield from asyncio.create_subprocess_shell('echo hi')
yield from p.wait()
asyncio.get_event_loop().run_until_complete(main())
Produces this output on Arch Linux und
Jack O'Connor added the comment:
My example script is definitely a corner case, but where this actually came up
for me was in asyncio. Using a TemporaryDirectory inside a coroutine creates a
similar situation.
--
___
Python tracker
New submission from Jack O'Connor:
The following test script prints a KeyboardInterrupt traceback (expected), but
also an AttributeError traceback (unexpected):
import asyncio
@asyncio.coroutine
def main():
raise KeyboardInterrupt
asyncio.get_event_loop().run_until_complete
New submission from Jack O'Connor:
The following little script prints (but ignores) a FileNotFoundError.
import tempfile
def generator():
with tempfile.TemporaryDirectory():
yield
g = generator()
next(g)
Exception ignored in:
Traceback (most recent call last):
File &q
Jack O'Connor added the comment:
Agreed that changing read() would probably break tons of people. I don't think
a naming inconsistency meets the "serious flaws are uncovered" bar for breaking
a provisional package. If we actually prefer the asyncio way of doing things,
a
New submission from Jack O'Connor:
BufferedIOBase and related classes have a read(n) and read1(n). The first will
wait until n bytes are available (or EOF), while the second will return as soon
as any bytes are available. In asyncio.StreamReader, there is no read1 method,
but the read m
51 matches
Mail list logo
