Hi Bors,
Apologis if my email came across as a bit harsh. I don¹t want to prune
things that are in active use. What I want to do is mainly to find out
which architectures people care about and get a better understanding of
who can/will maintain them.
One of the problems with a lot of ISAs in gem5 is unclear maintainership.
gem5 currently doesn¹t have a clear notion of architecture maintainers,
which I think is a bit of a problem. There are de facto maintainers for
x86 and ARM, but the other ISAs are for all practical purposes
unmaintained. I can, as you can probably understand, only really work on
ARM-related and core bits of the simulator. Similarly, AMD mainly works on
the x86 bits and the GPU bits.
The ideal outcome of this discussion would be that we formalise
maintainers for all of the ISAs and come up with a plan for unmaintained
ISAs.
To give you some background, I did some data mining on the repo to get an
estimate of the number of commits per ISA since 2012-01-01. These are the
stats:
ALPHA: 8 commits
ARM: 240 commits
MIPS: 11 commits
POWER: 11 commits (only ~5 of these are related to the POWER ISA, the rest
are related to power/energy modelling)
SPARC: 7 commits
x86: 158 commits
(for A in arm alpha x86 mips sparc power; do echo $A `git shortlog
--after=2012-01-01 -n | grep -i "^.*${A}.*:" |wc`; done)
This is obviously not a fool proof measure of the number of users, but it
does give you some background to what prompted us to start the discussion.
On 06/06/2016, 19:24, "gem5-dev on behalf of [email protected]"
<[email protected] on behalf of [email protected]> wrote:
>Hi Andreas,
>
>> POWER and MIPS.
>> [...]
>> They won't be missed.
>
>This is certainly not so here in my project where POWER and MIPS
>are the primary available options, and dropping them would be pretty
>much equivalent to discontinuing GEM5 altogether.
>
>What feels even more sad, is that I can see how the very presence of
>this discussion within the Overton window could be used by certain
>closed-source advocates to undermine our "community support" argument
>and thus try to weaken the position of not only our choice of GEM5
>but some neighbouring open-source choices as well.
Similar discussions have been held in the Debian and Fedora communities.
These sort of discussions are not new, if a component isn¹t maintained,
it¹s not unusual for open source projects to officially drop support for
it. At least until someone steps up to maintain the component. If you are
interested in maintaining these ISAs, we obviously shouldn¹t drop them.
The whole notion of community support hinges on there being a community.
Judging by the commit history for the past 4 years, you can only really
claim that there is community support for ARM and x86.
>>users submitting patches for them
>
>This one should easily exclude MIPS and POWER from candidates for
>phasing out, well at least I do submit MIPS and POWER patches which
>get merged into origin.
If you care about them enough to maintain them, then we should definitely
keep them. I don¹t want to scrap architectures for the sake of scrapping
them. It¹s about setting user expectations and knowing that someone cares
enough to fix issues as they crop up.
>>Ecosystem: We should phase out ISAs that don't have compiler
>> support. Being able to run code isn't very useful if you can't
>> compile code for the platform.
>
>True; and the above's implied connection to MIPS and/or POWER, sounds
>disturbing to me. Unless we assume a Redmond-like position that there
>is one OS and one compiler and one software stack (based on an 80%
>bell curve argument?), different people do different things and
>so the definition of "compiler support" varies from project to
>project. For example, in retargetable compilers (which is what I am
>interested in) there is more than a single project based on ArchC
>processor descriptions, and in that world, it's pretty much a
>three-ISA world of ARM, MIPS and POWER. I certainly hope SPARC
>to be equally usable soon too, but right now it's just barely limping;
>Alpha, yes there is a one-in-a-million chance; RISC-V, that's a very
>sweet dream indeed; and x86 seems even less likely.
>So yeah, three ISAs with compiler support that I could use, and like
>I said above, losing two of the three would not be much different
>from giving up on GEM5 altogether.
The ecosystem argument is mainly aiming at Alpha. Both MIPS and POWER have
actively supported toolchains.
>
>> We should phase out ISAS that don't support full-system
>> unless there is a clear plan to add that support.
>> (The NULL ISA is an exception)
>> Users expect to be able to run an OS if an ISA is supported.
Actually, this statement was probably not fair assessment of the state of
things. SE mode can be very useful, so please ignore it. :)
>
>From my chair it appears like this:
>In another kingdom far away, there are those other people doing
>those other extremely exciting things (including FS).
>
>For me, the catastrophic showstopper was broken remote debugging
>(gdb failing to even initiate the session) on every platform I tried,
>so I had to fix that. This was the majority of the defining
>discriminator between "working" and "not working"; FS didn't even
>enter into the picture.
That was much appreciated! It has been /extremely/ helpful for debugging a
few kernel issues I was encountering a couple of months back.
>
>On the other hand, I do completely agree with you about functional
>verification: I need to run a tall enough software stack (such as an
>OS kernel) to believe in the simulation. But I can have enormous
>stacks completely in SE. E.g. Java would serve as a good illustration
>(not that's what we use here) of such a huge SW stack having no
>relation to FS. I guess our situation here, is similar across the
>board: there is Jakub's system on SPARC which is obviously tall enough
>but not quite ready yet; then there is our stack which isn't there
>yet; and then I wouldn't be surprised to learn about other people
>with nontrivial workloads which are not the FS Linux kernel.
I completely agree with you. There are plenty of interesting things you
can do in SE mode. However, that depends on SE mode being functionally
correct having up-to-date kernel API support. We should definitely keep
SPARC (but consider retiring the Solaris test case) if we can get Jakub¹s
test case in there.
Functional correctness is probably my biggest pet peeve. During my PhD, I
had very painful experiences with gem5 and x86 which was far from
functionally correct. The kind of functional correctness issues I had
meant that only ~1/3 of SPEC could be run to completion and verify. I
simply cannot know how performance was affected by functional issues
affected convergence behaviour in the third that verified, but I suspect
it wasn¹t pretty. The bigger problem was that the breakdown of benchmarks
with issues was timing dependent, so changing the timing meant a new
benchmarks were braking. This was despite AMD caring about x86.
>>It reduces confusion among users. Having a handful of architectures
>> that are clearly incomplete and don't support full-system is not
>> very helpful to anyone.
>
>Does enabling projects which result in new compilers being written
>and papers being published in journals, count as helpful?
It¹s definitely helpful, but only as long as the behaviours of the
simulator are representative of real hardware. Again, users need to be
able to trust the simulator. A paper is only helpful if it reports
realistic behaviour. If the simulator is too broken to be representative
of the system you¹re simulating, the paper will be at best useless or at
worst misleading.
I hope that clarifies my position a bit. I really don¹t want to prune
things that are still useful, but we need to think about who maintains the
architectures that currently fall between the cracks.
Cheers,
Andreas
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
