Hi everyone,
I am facing a situation quite frequent in scientific computing: the
use of small and often short-lived data structures, where the overhead
of construction, element access, and garbage collection can easily
dwarf the cost of computation.
The classical example is Geometry in 3D space.
On Oct 21, 2013, at 11:33 AM, Konrad Hinsen wrote:
> Hi everyone,
>
> I am facing a situation quite frequent in scientific computing: the
> use of small and often short-lived data structures, where the overhead
> of construction, element access, and garbage collection can easily
> dwarf the cos
On Mon, Oct 21, 2013 at 12:47 PM, Matthias Felleisen
wrote:
>
> In general, it is a mistaken assumption however that even in a
> 'managed' language -- such as Java or Racket -- mutation is still
> faster than de/allocation of short-lived data structures. If you
> choose to go with 'managed' langua
WIth respect, I think this shows nothing :-)
On Oct 21, 2013, at 2:35 PM, Sam Tobin-Hochstadt wrote:
> On Mon, Oct 21, 2013 at 12:47 PM, Matthias Felleisen
> wrote:
>>
>> In general, it is a mistaken assumption however that even in a
>> 'managed' language -- such as Java or Racket -- mutat
I encourage you to find some evidence showing that Konrad's assumption
is mistaken, then.
Sam
On Mon, Oct 21, 2013 at 2:38 PM, Matthias Felleisen
wrote:
>
> WIth respect, I think this shows nothing :-)
>
>
>
> On Oct 21, 2013, at 2:35 PM, Sam Tobin-Hochstadt wrote:
>
>> On Mon, Oct 21, 2013 at
Sam Tobin-Hochstadt wrote at 10/21/2013 02:35 PM:
https://gist.github.com/samth/7088570
[...]
Direct is always fastest, multiple values are very slow, and cons is
always slower than mcons.
Is there any relatively low-hanging fruit optimization that can be done
for multiple-value returns
On Mon, Oct 21, 2013 at 3:36 PM, Neil Van Dyke wrote:
> Sam Tobin-Hochstadt wrote at 10/21/2013 02:35 PM:
>>
>> https://gist.github.com/samth/7088570
>>
>
> [...]
>
>> Direct is always fastest, multiple values are very slow, and cons is
>> always slower than mcons.
>
>
> Is there any relatively lo
On Mon, Oct 21, 2013 at 8:41 PM, Sam Tobin-Hochstadt
wrote:
> On Mon, Oct 21, 2013 at 3:36 PM, Neil Van Dyke
wrote:
>> Sam Tobin-Hochstadt wrote at 10/21/2013 02:35 PM:
>>>
>>> https://gist.github.com/samth/7088570
>>>
>>
>> [...]
>>
>>> Direct is always fastest, multiple values are very slow, an
Matthias Felleisen writes:
> You can count on Racket to inline a bunch of such small functions.
> You can use Optimization Coach to check on your understanding of
> what the compiler actually does, and you may benefit from its advice.
Optimization Coach sounds interesting, I'll install it ne
On Oct 22, 2013, at 6:46 AM, Konrad Hinsen wrote:
> fter today's
> explorations, I conclude that there's probably no difference between
> structs and vectors once I am in the Typed Racket universe, so I'll
> stick to structs for now.
Use vectors. At some point, you will want to iterate over th
Matthias Felleisen writes:
> On Oct 22, 2013, at 6:46 AM, Konrad Hinsen
> wrote:
>
> > structs and vectors once I am in the Typed Racket universe, so I'll
> > stick to structs for now.
>
> Use vectors. At some point, you will want to iterate over these
> things or access fields via com
Strange results. I did some benchmarks.
The 'mcons solution use always the same mcon to return the results of
all the function calls. It’s different from the 'cons solution that
returns a different con in each function call. I made a new version:
loop4 (see code bellow).
I ran the program 10 times
1. micro-benchmarks tell you nothing about this problem.
2. running something 10 times tells you little more.
3. running it on one architecture in one ENV tells you little more.
We have an internal reading list on performance evaluation but I think
it is now appropriate to list this:
ht
13 matches
Mail list logo
