If the JIT is eating it then you're right I'm absolutely fine with it. My
concern is driven because this is in the hot loop of the program and the
functions that are being called are fairly straightforward math that
accumulate results into an array, and I am pushing the performance limits
on th
On 02/24/2016 02:53 AM, Michael du Breuil wrote:
> The following (this is interop with libgdx if anyone is curious,
> hud-corner-top-left is a delayed TextureRegion
>
> (.draw batch ^TextureRegion @hud-corner-top-left
>(float -199)
>(float -32))
>
> Which yields the follow
A more reproduceable example:
(let [y (float 10)]
(println (str y)))
Yields this:
float y = RT.uncheckedFloatCast(10L);
((IFn)const__42.getRawRoot()).invoke(((IFn)const__43.getRawRoot()).invoke(Float.valueOf(y)));
On Wednesday, February 24, 2016 at 1:15:41 PM UTC-7, Michael d
(let [x (float -199)]
(.draw batch ^TextureRegion @hud-corner-top-left
x
(float -32)))
That's an interop call to libgdx. That generated the disassembly I pasted
before.
On Wednesday, February 24, 2016 at 5:05:30 AM UTC-7, Nicola Mometto wrote:
>
>
> > On 24 Feb 2016, at
I posted the disassembly from the AOT'd result, so I'm pretty clearly still
seeing all the casting happening at runtime. I'm not sure why that is
different then no.disassemble...
On Wednesday, February 24, 2016 at 5:05:30 AM UTC-7, Nicola Mometto wrote:
>
>
> > On 24 Feb 2016, at 11:58, Michael
Can you post the actual code you're compiling?
> On 24 Feb 2016, at 20:03, Michael du Breuil
> wrote:
>
> I posted the disassembly from the AOT'd result, so I'm pretty clearly still
> seeing all the casting happening at runtime. I'm not sure why that is
> different then no.disassemble...
>
> On 24 Feb 2016, at 11:58, Michael du Breuil
> wrote:
>
> That just performs a runtime cast to a variable then reference the variable
> later, which is even worse.
>
> float x = RT.uncheckedFloatCast(-199L);((SpriteBatch)batch)
>
> .draw((TextureRegion)((IFn)const__5.getRawRoot()).inv
That just performs a runtime cast to a variable then reference the variable
later, which is even worse.
float x = RT.uncheckedFloatCast(-199L);((SpriteBatch)batch)
.draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__42.getRawRoot()),
x,
RT.uncheckedFloatCast(-32
Those are runtime casts, this is the expected behaviour (although one could
argue that clojure should be able to optimize them away at compile time).
If you want to avoid the runtime casting, you can do something like this:
(let [x (float 123)]
(defn y [..]
(.foo bar x)))
> On 24 Feb 2
The following (this is interop with libgdx if anyone is curious,
hud-corner-top-left is a delayed TextureRegion
(.draw batch ^TextureRegion @hud-corner-top-left
(float -199)
(float -32))
Which yields the following:
.draw((TextureRegion)((IFn)const__5.getRawRoot()).in
Can you post the code?
> On 24 Feb 2016, at 10:26, Michael du Breuil
> wrote:
>
> I have some interop code that I have carefully specified all the arguments to
> be in the correct type (IE the function signature takes 3 floats, so I cast
> everything to float so that I can avoid reflection).
I have some interop code that I have carefully specified all the arguments
to be in the correct type (IE the function signature takes 3 floats, so I
cast everything to float so that I can avoid reflection). What I'm
surprised by is compile time constants such as (float -173) or (float 8.5)
are
12 matches
Mail list logo
