Hi Andreas, others,
EPEL looks promising; I'll look into if that tips the scales for our
admin people. Thanks.
As far as traces go, I'm not up to speed on what precisely the problem
is or how protobuf solves it, so I can't really suggest other solutions.
I know that's not the most helpful thing to say.
Thing is, gem5 is already a complicated piece of software (in terms of
code structure, dependencies, compilation, configuration, running), and
every further complication will scare away some percentage of would-be
users. As a user rather than a developer, and one who doesn't have a
pressing need for traces, I wonder if there's a case for trying to
simplify what's already there before adding a further complications?
-Erik
On 10/12/12 14:37, Andreas Hansson wrote:
Eric, another minor note on the topic of Scientific Linux, perhaps you can
convince the sysadmin's to have a look at EPEL
(http://fedoraproject.org/wiki/EPEL) both for gperftools and protobuf.
yum install epel-release&& yum install protobuf should do the trick :-)
Andreas
On 10/12/2012 14:22, "Andreas Hansson"<[email protected]> wrote:
Hi Eric,
Thanks for your input.
The dependency is indeed generating some additional issues in the type of
environments you describe, and Scientific Linux does seem to be a bit
behind. Luckily, it should not involve more than a configure, make and
make install to get it up and running.
The big question is: what portion of the users does it affect (I would
think most people could get away with installing the package), and are the
benefits of protobuf large enough to warrant the additional burden?
Independent of the answer to this question, we need a path forward to
support input/output of memory traces and execution traces. The protobuf
solution seems to be much better than any other option in solving this
problem, in many aspects, e.g. portability, size, speed, effort. What do
you suggest instead?
Kind regards,
Andreas
On 10/12/2012 11:58, "Erik Tomusk"<[email protected]> wrote:
As one of the proverbial users whose experience is under discussion,
maybe I can butt in.
I think it's important to realize that not everyone uses self-managed
machines with root access. I, for one, don't have root or access to a
package manager on my regular work machine (Scientific Linux 6). SL6
seems to lag RHEL with package support, so as far as I can tell,
protobuf (and even tcmalloc) are not installed and not even available
(http://ftp.scientificlinux.org/linux/scientific/6rolling/x86_64/os/Packa
g
es/)
If I want these libraries, I need to build them and any dependencies
locally from tarballs or convince the admins to do it. If the admins are
convinced and manually build the libs (unlikely), they then need to
schedule reboots for all the machines in the school. Fun fun.
I could, of course, switch to a self-managed desktop machine, except
that I need to regularly run lots of things on our server farm. This is
where it gets really interesting. Given that the farm admins have a
responsibility to keep the farm running for all the various groups
buying compute resources, there's no way they're going to manually build
libraries not officially supported by the distro and then support those
libraries for the rest of time (I already tried to convince them on
libperftools--no dice). Again I need to build the libraries locally and
then make sure that everything works across a finicky server farm, all
it's various nodes and whatnot.
Since I've already invested so much time into using gem5, if another
dependency comes on board, I'll just have to make it work (or not
upgrade). I doubt a newbie would go through all this trouble, though.
-Erik
On 09/12/12 16:09, Ali Saidi wrote:
On Dec 9, 2012, at 8:53 AM, Nilay Vaish wrote:
On Sun, 9 Dec 2012, Andreas Hansson wrote:
May I ask why you see this as a problem? Any Unix/Linux/OSx system
>from the last 5+ years has these dependencies as packages (and I bet
they work smoother than e.g. swig :-)
I doubt that this statement is true. I am using RHEL 6 and it does not
have protoc installed. I am guessing that would mean people who use
Fedora will not have it installed either. Ubuntu (12.10) has it. I
don't know about Mint or other distributions.
As far as package availability protobufs is available since Fedora 16
as well as EL6. It's also available in all currently supported Ubuntu
versions as well as mint and debian and just about everything else:
http://pkgs.org/search/?keyword=protobuf
So I think package availability is a separate concern from user
experience. It's absolutely true that there would be another dependency,
the question in my mind is that dependency a larger burden than we
currently expect from the user and are the benefits of the library worth
it? I think this is the best possible path toward being able to output
memory traces, which we do seem to get a fair number of requests for on
the mailing list.
This may not affect ARM, but one of the reasons why I am involved with
gem5 is that I would like people in architecture to be using the
simulator that I have contributed to.
I think ARM is completely committed making gem5 successful in the
broader architecture community, as evidenced by the large number of
change sets with committers from ARM.
Ali
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
-- 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
-- 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
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
