Have we become too Intel x64 centered?

classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Have we become too Intel x64 centered?

Boost - Dev mailing list
I have no solution for this, but I note that neither do we have CI, nor
tests on
https://www.boost.org/development/tests/develop/developer/summary.html 
that aren't Intel x86.  The compiler list has shrunk to msvc/clang/gcc
as well.

I note that at least in theory, other platforms/architectures could be
integrated into Drone CI (either the CppAlliance one, or our own), but
someone would have to offer to host the clients running the tests.

Any thoughts/solutions?

Cheers, John.


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
On 1/23/21 2:20 PM, John Maddock via Boost wrote:

> I have no solution for this, but I note that neither do we have CI, nor
> tests on
> https://www.boost.org/development/tests/develop/developer/summary.html 
> that aren't Intel x86.  The compiler list has shrunk to msvc/clang/gcc
> as well.
>
> I note that at least in theory, other platforms/architectures could be
> integrated into Drone CI (either the CppAlliance one, or our own), but
> someone would have to offer to host the clients running the tests.
>
> Any thoughts/solutions?

As a maintainer of Boost.Atomic, I would appreciate more hardware
architectures, especially ARM. The real hardware is not mandatory for
this, as it could be emulated with QEMU, although the performance would
suffer (but could still be acceptable). Currently, I'm running this
setup locally. The question is who is going to run these QEMU VMs in the
cloud and how much it will cost.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
On Sat, Jan 23, 2021 at 6:14 AM Andrey Semashev via Boost <
[hidden email]> wrote:

> On 1/23/21 2:20 PM, John Maddock via Boost wrote:
> > I have no solution for this, but I note that neither do we have CI, nor
> > tests on
> > https://www.boost.org/development/tests/develop/developer/summary.html
> > that aren't Intel x86.  The compiler list has shrunk to msvc/clang/gcc
> > as well.
> >
> > I note that at least in theory, other platforms/architectures could be
> > integrated into Drone CI (either the CppAlliance one, or our own), but
> > someone would have to offer to host the clients running the tests.
> >
> > Any thoughts/solutions?
>
> As a maintainer of Boost.Atomic, I would appreciate more hardware
> architectures, especially ARM. The real hardware is not mandatory for
> this, as it could be emulated with QEMU, although the performance would
> suffer (but could still be acceptable). Currently, I'm running this
> setup locally. The question is who is going to run these QEMU VMs in the
> cloud and how much it will cost.
>

I've got a couple raspberry pi 4's that are running tests (slowly, takes
20+hrs to run the test suite...any earlier models just didn't have enough
ram). Look at the teeks99-05* (armv71/armhf) and teeks99-06* (aarch64).

If anyone has access to a RISC-V development board, I'd like to get my
hands on one of those to start running too.

I've debated trying QEMU for more variety, but that has always taken a
back seat to getting the working compilers providing results more quickly.

At one point we had some person/group/company that was targeting android
and had the tests running. That seems like a big hole in what we
test....being the most widely used computing platform and all. Not sure
what would be needed to get that going again.

Tom

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, 23 Jan 2021, John Maddock via Boost wrote:

> I have no solution for this, but I note that neither do we have CI, nor
> tests on
> https://www.boost.org/development/tests/develop/developer/summary.html 
> that aren't Intel x86.  The compiler list has shrunk to msvc/clang/gcc
> as well.

https://www.boost.org/development/testing.html does not link to
explanations on how to add testers, not very encouraging. The bottom still
says literally "Revised $Date$" so maybe that page is dead.

Why not use the gcc testfarm? Despite the name, it isn't at all restricted
to gcc. It has some aarch64, sparc64, ppc64, etc. Of course you shouldn't
abuse it by running a CI on every commit, but running the testsuite once a
week on aarch64 should be no problem I believe. An advantage is that
developers would have access to the platform, so they would have an easier
time reproducing issues than with other testers.

--
Marc Glisse

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 1/23/21 3:47 PM, Tom Kent via Boost wrote:
>
> I've got a couple raspberry pi 4's that are running tests (slowly, takes
> 20+hrs to run the test suite...any earlier models just didn't have enough
> ram). Look at the teeks99-05* (armv71/armhf) and teeks99-06* (aarch64).

I appreciate your and all other testers efforts in running the test
suite, but I must confess that I pay almost no attention to the official
test matrix these days because:

- No notifications of build/test failures or test completions. Having to
manually visit the page from time to time is a problem, especially given
the...
- Slow turnaround times. As I remember, for some testers the turnaround
time was days and weeks. For others it was better, but still not as good
as AppVeyor, which usually sends the notification in a few hours after
the commit.
- Problematic debugging. Often the report shows a failure, but the error
log is not accessible. This seems to be a long standing problem. This
makes the whole testing process pointless, as I cannot do anything about
the failures.

I wish the current testing infrastructure was replaced with something
more modern, CI-style, as I don't believe the above issues will be fixed
any time soon.

> If anyone has access to a RISC-V development board, I'd like to get my
> hands on one of those to start running too.
>
> I've debated trying QEMU for more variety, but that has always taken a
> back seat to getting the working compilers providing results more quickly.

Given that compile times probably dominate the run times, I wonder if it
would be better to do a cross-compile on x86 and then run on the real
hardware or a QEMU VM, in terms of test turnaround. I realize that this
setup is much more complex, but it could be the game changer.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
John Maddock wrote:

> I have no solution for this, but I note that neither do we have CI, nor
> tests on
> https://www.boost.org/development/tests/develop/developer/summary.html 
> that aren't Intel x86.

Travis has support for ARM64, ppc64le, s390x. Of those, only the last one is
big-endian.

See e.g. the first four entries of
https://travis-ci.org/github/boostorg/endian/builds/750954473.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, Jan 23, 2021 at 7:10 AM Marc Glisse via Boost <[hidden email]>
wrote:

> On Sat, 23 Jan 2021, John Maddock via Boost wrote:
>
> > I have no solution for this, but I note that neither do we have CI, nor
> > tests on
> > https://www.boost.org/development/tests/develop/developer/summary.html
> > that aren't Intel x86.  The compiler list has shrunk to msvc/clang/gcc
> > as well.
>
> https://www.boost.org/development/testing.html does not link to
> explanations on how to add testers, not very encouraging. The bottom still
> says literally "Revised $Date$" so maybe that page is dead.
>
> Why not use the gcc testfarm? Despite the name, it isn't at all restricted
> to gcc. It has some aarch64, sparc64, ppc64, etc. Of course you shouldn't
> abuse it by running a CI on every commit, but running the testsuite once a
> week on aarch64 should be no problem I believe. An advantage is that
> developers would have access to the platform, so they would have an easier
> time reproducing issues than with other testers.
>
>
Interesting, the GCC Compile Farm (https://gcc.gnu.org/wiki/CompileFarm)
looks like it has quite a few architectures. I applied for an account
there. I think it would be pretty easy to get some boost test jobs running
weekly-ish across different architectures.

I know it is hosted by the GCC people, but do they have qualms about
running our tests against clang too? I can ask on that list, just wondering
if you have any knowledge.

Tom

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Andrey Semashev via Boost said:     (by the date of Sat, 23 Jan 2021 18:38:04 +0300)

> - No notifications of build/test failures or test completions. Having to
> manually visit the page from time to time is a problem, especially given
> the...


you might want to switch to gitlab package. No need to use their
site, it is also packaged e.g. for debian to use on any server.

Recently I configured CI for ppc64el, arm64 [1], there is a full log
in the pipeline [2] and email alert in case of failure. I needed to
install qemu-user-static version above 5.0-14 on the host

   apt-get install binfmt-support qemu-user-static

Then this command starts docker inside emulator:

  docker run -it --rm multiarch/debian-debootstrap:ppc64el-bullseye  bash

best regards
Janek

[1] https://gitlab.com/yade-dev/trunk/-/merge_requests/588
[2] e.g. https://gitlab.com/yade-dev/trunk/-/pipelines/245472012 click "Show complete raw" icon.


--
# Janek Kozicki                              http://janek.kozicki.pl/

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, Jan 23, 2021 at 3:21 AM John Maddock via Boost
<[hidden email]> wrote:
> I note that at least in theory, other platforms/architectures could be
> integrated into Drone CI (either the CppAlliance one, or our own), but
> someone would have to offer to host the clients running the tests.

I'm not really a fan of the Boost development test matrix, because it
has a low signal to noise ratio. That is, often there are errors
reported which are spurious, or due to a misconfiguration. And when
the errors are real, the log is often unhelpful and lacks sufficient
context to diagnose and treat the problem. On the other hand I very
much used to like Travis, and Drone CI is a close approximation to
Travis.

That said, the C++ Alliance Drone CI instance is destined to become
the dedicated Boost Drone CI service (we are still working out the
kinks). This service will be available for all Boost libraries. Sam
has been working on integration scripts to get existing Boost
repositories to build on it.

If there are requests for other platforms, I believe we can add them
using the virtual emulation (qemu?). Sam Darwin is the lead on this
and he monitors the mailing list so feel free to reach out and make
requests.

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 1/23/2021 6:20 AM, John Maddock via Boost wrote:

> I have no solution for this, but I note that neither do we have CI, nor
> tests on
> https://www.boost.org/development/tests/develop/developer/summary.html 
> that aren't Intel x86.  The compiler list has shrunk to msvc/clang/gcc
> as well.
>
> I note that at least in theory, other platforms/architectures could be
> integrated into Drone CI (either the CppAlliance one, or our own), but
> someone would have to offer to host the clients running the tests.
>
> Any thoughts/solutions?

Is there information anywhere showing which CPUs/platforms the major
compilers ( vc++, clang, gcc, Intel C++, Oracle C++ ) run on, along with
how to run CI tests ( appveyor, travis CI, ??? ) on those CPUs/platforms  ?

I have always personally found that figuring out how the major CIs work
is a great deal of effort setting up for a Boost library for little
additional gain.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

> I've got a couple raspberry pi 4's that are running tests (slowly, takes
> 20+hrs to run the test suite...any earlier models just didn't have enough
> ram). Look at the teeks99-05* (armv71/armhf) and teeks99-06* (aarch64).
Thanks Tom, I had missed those!

>
> If anyone has access to a RISC-V development board, I'd like to get my
> hands on one of those to start running too.
>
> I've debated trying QEMU for more variety, but that has always taken a
> back seat to getting the working compilers providing results more quickly.
>
> At one point we had some person/group/company that was targeting android
> and had the tests running. That seems like a big hole in what we
> test....being the most widely used computing platform and all. Not sure
> what would be needed to get that going again.
>
> Tom
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 23/01/2021 15:38, Andrey Semashev via Boost wrote:

> On 1/23/21 3:47 PM, Tom Kent via Boost wrote:
>>
>> I've got a couple raspberry pi 4's that are running tests (slowly, takes
>> 20+hrs to run the test suite...any earlier models just didn't have
>> enough
>> ram). Look at the teeks99-05* (armv71/armhf) and teeks99-06* (aarch64).
>
> I appreciate your and all other testers efforts in running the test
> suite, but I must confess that I pay almost no attention to the
> official test matrix these days because:
>
> - No notifications of build/test failures or test completions. Having
> to manually visit the page from time to time is a problem, especially
> given the...
> - Slow turnaround times. As I remember, for some testers the
> turnaround time was days and weeks. For others it was better, but
> still not as good as AppVeyor, which usually sends the notification in
> a few hours after the commit.
> - Problematic debugging. Often the report shows a failure, but the
> error log is not accessible. This seems to be a long standing problem.
> This makes the whole testing process pointless, as I cannot do
> anything about the failures.
>
> I wish the current testing infrastructure was replaced with something
> more modern, CI-style, as I don't believe the above issues will be
> fixed any time soon.

This is much how I feel - I confess to having been a CI Luddite when it
first appeared, but there's no question it does streamline things.



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 23/01/2021 15:47, Peter Dimov via Boost wrote:

> John Maddock wrote:
>
>> I have no solution for this, but I note that neither do we have CI,
>> nor tests on
>> https://www.boost.org/development/tests/develop/developer/summary.html 
>> that aren't Intel x86.
>
> Travis has support for ARM64, ppc64le, s390x. Of those, only the last
> one is big-endian.
>
> See e.g. the first four entries of
> https://travis-ci.org/github/boostorg/endian/builds/750954473.

Thanks Peter, I confess I hadn't realized they'd expanded to these other
architectures.

Longer term, I confess I could never see how Travis or the other free
providers could afford to do what they're doing and not be overwhelmed.



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 23/01/2021 16:22, Edward Diener via Boost wrote:

> On 1/23/2021 6:20 AM, John Maddock via Boost wrote:
>> I have no solution for this, but I note that neither do we have CI,
>> nor tests on
>> https://www.boost.org/development/tests/develop/developer/summary.html 
>> that aren't Intel x86.  The compiler list has shrunk to
>> msvc/clang/gcc as well.
>>
>> I note that at least in theory, other platforms/architectures could
>> be integrated into Drone CI (either the CppAlliance one, or our own),
>> but someone would have to offer to host the clients running the tests.
>>
>> Any thoughts/solutions?
>
> Is there information anywhere showing which CPUs/platforms the major
> compilers ( vc++, clang, gcc, Intel C++, Oracle C++ ) run on, along
> with how to run CI tests ( appveyor, travis CI, ??? ) on those
> CPUs/platforms  ?
No, and this is the issue - every CI provider has their own arcane
syntax and list of supported OS images.
>
> I have always personally found that figuring out how the major CIs
> work is a great deal of effort setting up for a Boost library for
> little additional gain.
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
John Maddock wrote:
> I have no solution for this, but I note that neither do we have CI, nor
> tests on
> https://www.boost.org/development/tests/develop/developer/summary.html 
> that aren't Intel x86.? The compiler list has shrunk to msvc/clang/gcc
> as well.

For a while in 2017-2018 I was running ARM64 tests on Scaleway hardware
which appeared in the test matrix. I had the impression no-one ever took
any interest.

It would not be difficult to set this up on AWS ARM instances, though there
would be some costs involved. Interestingly AWS now also has x86 Macs
though they aren't cheap.

If anyone fancies something even more exotic to experiment with, how
about Emscripten / Wasm? In my limited experience, header-only Boost
seems to work OK though I do get a few warnings. It is an interesting
platform these days because it is 32-bit. I think that running tests
on it could be quite a challenge!


Regards, Phil.





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
John Maddock wrote:

> Thanks Peter, I confess I hadn't realized they'd expanded to these other
> architectures.
>
> Longer term, I confess I could never see how Travis or the other free
> providers could afford to do what they're doing and not be overwhelmed.

In this specific case I suppose they are using IBM-donated computing power
which is a more sustainable "business model" than paying MacStadium or
whoever.

Github Actions is very usable and covers the common cases (gcc-4.7 to -10,
clang 3.5 to 11, msvc 14.1 and 14.2, macos-10.15) so Travis can be used only
for the rest (https://travis-ci.org/github/boostorg/core/builds/755272662).

To enable Github Actions for your repo, just copy e.g.
https://github.com/boostorg/core/blob/develop/.github/workflows/ci.yml into
the same directory. No other steps are needed.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
On 23/01/2021 17:48, Peter Dimov via Boost wrote:

> John Maddock wrote:
>
>> Thanks Peter, I confess I hadn't realized they'd expanded to these
>> other architectures.
>>
>> Longer term, I confess I could never see how Travis or the other free
>> providers could afford to do what they're doing and not be overwhelmed.
>
> In this specific case I suppose they are using IBM-donated computing
> power which is a more sustainable "business model" than paying
> MacStadium or whoever.
>
> Github Actions is very usable and covers the common cases (gcc-4.7 to
> -10, clang 3.5 to 11, msvc 14.1 and 14.2, macos-10.15) so Travis can
> be used only for the rest
> (https://travis-ci.org/github/boostorg/core/builds/755272662).
>
> To enable Github Actions for your repo, just copy e.g.
> https://github.com/boostorg/core/blob/develop/.github/workflows/ci.yml 
> into the same directory. No other steps are needed.

Nod.  Math and Multiprecision are slowly getting their CI's updated
which is what prompted the original message, we will probably try to
balance the permutations between the different services to keep things
as speedy as possible (and avoid hogging too much of any one services
time).  And yes, GHA are super quick - color me impressed! :)

John.


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
John Maddock wrote:

> Nod.  Math and Multiprecision are slowly getting their CI's updated which
> is what prompted the original message, we will probably try to
balance the permutations between the different services to keep things as
speedy as possible (and avoid hogging too much of any one services time).
And yes, GHA are super quick - color me impressed! :)

Interesting, so it has msvc-14.0 now as well, didn't know that.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
  > The compiler list has shrunk to msvc/clang/gcc
> as well.

> I note that at least in theory, other platforms/architectures could be
> integrated into Drone CI (either the CppAlliance one, or our own), but
> someone would have to offer to host the clients running the tests.

> Any thoughts/solutions?
Yes. Numerous... thoughts I guess.
Thanks for raising this issue.
Having spent half a lifetime in the exciting embeddedworld it's fascinating to see how "big" some of these"little" microcontrollers have become, and how wellcertain embedded compilers are actuallyrising to the challenge of keeping up withmodern C++ progress.
This post brings thoughts (back) to mind.* How cool would it be investigate more on whichpart(s) of Boost lend themselves well (or not)to deeply embedded systems.* How to leverage more power of cross-compiling.
* How to work toward more "green" CI philosophies.
Regarding these, you can already handilycross-build directly on your Ubuntu pipeline witharm-none-eabi for the architectures of"famous stars" like RPI and BBB. Little modificationsin bjam could handle cross compilers installedwith sudo apt. In fact, I recently set up somecross builds for arm-none-eabi-gcc onGitHub Actions.

OK, great... you say, build, but not run.They do not run at that point, but you find outlots of preliminary problems even trying to buildthe software on the cross-compiler.
Cross-compiling will in general make your codemore portable.
On the other note, I personally find that systemssuch as Raspberry PI and BeagleBone do, in fact,have comparatively high power-consumptionfor the actual yielded CPU power that is attainedfrom them. With relatively outdated cores,comparatively small caches and predominantlyoff-board RAM, they are at a disadvantage.Fast and modern microcontroller-based systemswith today's state-of-the-art embedded controllerscould be much more energy efficient. Thiswould be more on the research end of things,how to make a fast, future-ready, greenerembedded CI cluster...
Kind regards, Chris
   On Saturday, January 23, 2021, 12:21:13 PM GMT+1, John Maddock via Boost <[hidden email]> wrote:  
 
 I have no solution for this, but I note that neither do we have CI, nor
tests on
https://www.boost.org/development/tests/develop/developer/summary.html 
that aren't Intel x86.  The compiler list has shrunk to msvc/clang/gcc
as well.

I note that at least in theory, other platforms/architectures could be
integrated into Drone CI (either the CppAlliance one, or our own), but
someone would have to offer to host the clients running the tests.

Any thoughts/solutions?

Cheers, John.


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Have we become too Intel x64 centered?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 1/23/21 7:38 AM, Andrey Semashev via Boost wrote:
> On 1/23/21 3:47 PM, Tom Kent via Boost wrote:
>>
>> I've got a couple raspberry pi 4's that are running tests (slowly, takes
>> 20+hrs to run the test suite...any earlier models just didn't have enough
>> ram). Look at the teeks99-05* (armv71/armhf) and teeks99-06* (aarch64).
>
> I appreciate your and all other testers efforts in running the test
> suite, but I must confess that I pay almost no attention to the official
> test matrix these days because:

The boost test matrix is the most complete and reliable display of the
current state of the the boost packages.  I do run the more moder CI
stuff, but it's often failing for some issue or another totally
unrelated to my library.  It's the gold standard as far as I'm concerned.
>
> - No notifications of build/test failures or test completions. Having to
> manually visit the page from time to time is a problem, especially given
> the...
This bothers me not at all.
> - Slow turnaround times. As I remember, for some testers the turnaround
> time was days and weeks. For others it was better, but still not as good
> as AppVeyor, which usually sends the notification in a few hours after
> the commit.


> - Problematic debugging. Often the report shows a failure, but the error
> log is not accessible. This seems to be a long standing problem. This
> makes the whole testing process pointless, as I cannot do anything about
> the failures.

I have difficulties sifting through the test output on all platforms.
(I've been roundly ridiculed for this complaint.  But it means nothing
to me - I wear their ridicule as a badge of honor.)  I have my own
solution which I run on my own machine - library_status which presents a
table which is actually more useful to me than the official boost one
not to mention the Appveyor one.  Now If I could get library_status to
run as part of the CI solutions ...
>
> I wish the current testing infrastructure was replaced with something
> more modern, CI-style, as I don't believe the above issues will be fixed
> any time soon.

I've made a worthy proposal for that (to be used in addition to the
current boost test matrix).  Again, got a lot of ridicule on that one too.
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123