From: ericonr <ericonr@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: pari: add config options
Date: Sun, 28 Mar 2021 08:12:21 +0200 [thread overview]
Message-ID: <20210328061221.c2jDNFTDYlWoQ_UTle8Rfgoq2EzNGM7wy_G0Q9WQw6M@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-29635@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/pull/29635#issuecomment-808853504
Comment:
Two quick nits on the current PR: the `pari` commit messages should be squashed together, and the `giac` commit should include `update to $version`, instead of just `update` :)
@tornaria, thanks for the thorough analysis.
> I think the reason is that TLS is slow.
This shouldn't affect things so much, unless they made the terrible decision of using `__thread` globals for everything? Or worse, normal global with `pthread_mutex` calls around accesses...
> I wonder if it would make sense to offer different versions of pari (single thread / multi thread). At the very least, I'd make pthread a build option so that one can easily compile one or the other as needed.
That sounds reasonable, especially since there seems to be such a difference.
> Is there a way void could support something like "subarchitectures"? Say x86_64-avx where some packages are compiled for this architecture and the rest default to the packages for x86_64.
Maybe as a build option, at most. I don't believe we wish to carry such packages, because it can increase the maintenance burden a lot. If the threaded version becomes necessary for sage (as a system package) but the performance loss is too high, we can consider it then, but I'm against it when it comes to architecture. Ideally, they would compile opimitized versions of some files and choose between them at runtime...
next prev parent reply other threads:[~2021-03-28 6:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-20 17:20 [PR PATCH] " dkwo
2021-03-22 9:31 ` [PR PATCH] [Updated] " dkwo
2021-03-25 3:11 ` [wip] " ericonr
2021-03-25 20:21 ` [PR PATCH] [Updated] " dkwo
2021-03-25 20:23 ` dkwo
2021-03-26 9:51 ` dkwo
2021-03-26 16:30 ` ericonr
2021-03-26 17:09 ` dkwo
2021-03-26 17:42 ` ericonr
2021-03-27 14:53 ` [PR PATCH] [Updated] " dkwo
2021-03-27 14:58 ` dkwo
2021-03-27 19:39 ` tornaria
2021-03-27 22:28 ` tornaria
2021-03-27 22:38 ` tornaria
2021-03-28 6:12 ` ericonr [this message]
2021-03-28 6:13 ` ericonr
2021-03-28 10:10 ` [PR PATCH] [Updated] " dkwo
2021-03-28 10:11 ` dkwo
2021-03-28 14:23 ` tornaria
2021-03-28 19:15 ` [wip] " dkwo
2021-04-07 12:59 ` dkwo
2021-05-06 18:17 ` [PR PATCH] [Closed]: " dkwo
2021-08-17 19:06 ` tornaria
2021-08-17 19:42 ` ericonr
2021-08-17 21:41 ` tornaria
2021-08-18 9:15 ` dkwo
2021-08-18 9:15 ` [PR PATCH] [Closed]: " dkwo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210328061221.c2jDNFTDYlWoQ_UTle8Rfgoq2EzNGM7wy_G0Q9WQw6M@z \
--to=ericonr@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).