<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 21, 2017 at 9:05 PM, Ben Coman <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Good initiative, but I guess satisfying both  "> 20KLOC"  and<br>
"portable"  at the same time may be a tough ask.<br></blockquote><div><br></div><div>You are right, what I meant is not _too much_ dependent in the dialect. Anyway, my experience from porting Smark benchs from Pharo to Bee is that I had to add ~20 methods and change some selectors here and there.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Just a very random thought - I wonder if any insight might be gained<br>
by crossing several of the low level together.<br>
Like run a compute intensive benchmark at the same time as a memory<br>
intensive benchmark?<br>
<br>
cheers -ben<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Mar 22, 2017 at 7:53 AM, Javier Pimás<br>
<<a href="mailto:elpochodelagente@gmail.com">elpochodelagente@gmail.com</a>> wrote:<br>
><br>
> Hi everybody! While measuring performance I usually face the problem of assessing performance. At present, I'm using are-we-fast-yet benchs and also smark ones, among others. Unfortunately, for some purposes those benchs are considered too low-level, so I'd like to collect a set of "real world" fat workloads. I'm asking for contributions on computing problems you have. I'll create a public repo as a common place,  explaining what each bench does, so that we can all benefit from the result.<br>
><br>
> The code should have the following properties:<br>
><br>
> - The executed code should be > 20KLOC.<br>
> - It should have compute or memory intensive models or both.<br>
> - Ideally, it has sufficient run time, perhaps a few minutes, but at least a few seconds.<br>
> - The results should be verifiable.<br>
> - The more portable the best, as I need to have those benchs running in another dialect.<br>
> - Should be fully automate-able, it should be possible to suppress output.<br>
><br>
><br>
> Some examples are moose models, source code analysis, parallelization, web apps, parser generators, their corresponding parsers, XML processing, report generation, refactoring tools, type inference, etc…<br>
><br>
> Feel free to forward this mail to other lists you consider appropriate.<br>
><br>
> Cheers,<br>
> Pocho<br>
><br>
> --<br>
> Javier Pimás<br>
> Ciudad de Buenos Aires<br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Javier Pimás<br>Ciudad de Buenos Aires</div></div>
</div></div>