haha thanks for pointing out that as usual, they've cooked their
benchmarks.
also, I haven't seen a lot of papers out of DESRES lately that aren't pure
software (vs. some actual science finding). Maybe speed isn't everything 😜
I can definitely attest to numerical stability issues on Anton machines...
I don't miss being confused that much by simple tasks
Robin
On Thu, May 13, 2021, 12:27 PM Scott Le Grand <varelse2005.gmail.com> wrote:
> So, we're all getting our knickers in a bunch over an Apples to Oranges
> Desmond to AMBER performance comparison.
>
> Please don't...
>
> They cheated, because that's what they do to keep their investors happy.
> They used a 32^3 grid, and they skipped calculating the Ewald Sum every
> other iteration (thanks Adrian!). Rather than get upset here, point and
> laugh at DE Shaw et al. that they are afraid to go head to head with AMBER,
> and if they do (and they won't because they're chicken bawk bawk bawk), we
> have the people to address that as well.
>
> At our end, there's a ~50% or so performance deficit in AMBER 20 we need to
> fix. I've already fixed 2/3 of that building PMEMD 2.0 (770 ns/day DHFR 2
> fs already). Let them prance about with their greasy kids stuff desperate
> approximations and cheats, SPFP remains performance and accuracy with
> compromise and if they want to pick a fight with SPFP, make them do the
> work to demonstrate equivalent numerical stability (spoilers: they won't
> because they can't but oh the bellyacheing and handwaving they are willing
> to do, just watch).
>
> Scott
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu May 13 2021 - 13:00:02 PDT
