What Are You Working On? V13

[turb_]

[QUOTE=arienh4;25130016]Actually, the AOT compiler produces better code since it can do optimizations which would take too long to be done JIT.[/QUOTE]

However good the AOT optimizations are, surely they can't match the fact that the JIT can optimize for the specific architecture?

[arienh4]

[QUOTE=turb_;25130058]However good the AOT optimizations are, surely they can't match the fact that the JIT can optimize for the specific architecture?[/QUOTE]
AOT is always for one specific architecture. You can't run anything that's compiled AOT on .NET to another architecture.

There's a reason the entire .NET Framework is compiled AOT when you install it.

[jA_cOp]

[QUOTE=arienh4;25130016]Actually, the AOT compiler produces better code since it can do optimizations which would take too long to be done JIT.[/QUOTE]

The JIT compiler can also do optimizations that the AOT compiler can't, and I can imagine the JIT compiler being much more advanced due to being the default. But no proof of either have been presented in this thread, so it's kind of a moot argument.

[esalaka]

[QUOTE=jA_cOp;25131624]The JIT compiler can also do optimizations that the AOT compiler can't, and I can imagine the JIT compiler being much more advanced due to being the default. But no proof of either have been presented in this thread, so it's kind of a moot argument.[/QUOTE]

JIT compiler can do runtime optimizations that will make the program faster.
AOT compiler can do compile-time optimizations that take time and potentially make program faster.

[arienh4]

[QUOTE=jA_cOp;25131624]The JIT compiler can also do optimizations that the AOT compiler can't, and I can imagine the JIT compiler being much more advanced due to being the default. But no proof of either have been presented in this thread, so it's kind of a moot argument.[/QUOTE]
The AOT compiler equals the JIT compiler with more time on its hands.
[QUOTE=esalaka;25131699]JIT compiler can do runtime optimizations that will make the program faster.
AOT compiler can do compile-time optimizations that take time and potentially make program faster.[/QUOTE]
What kind of runtime optimizations can the JIT compiler do that the AOT compiler cannot?

[jA_cOp]

[QUOTE=esalaka;25131699]JIT compiler can do runtime optimizations that will make the program faster.
AOT compiler can do compile-time optimizations that take time and potentially make program faster.[/QUOTE]

... ok? What?

[QUOTE=arienh4;25131794]
What kind of runtime optimizations can the JIT compiler do that the AOT compiler cannot?[/QUOTE]

Quite a few. [url=http://stackoverflow.com/questions/538056/jit-compiler-vs-offline-compilers/538107#538107]This SO post sums it up pretty well[/url].

[arienh4]

[QUOTE=jA_cOp;25131851]... ok? What?

Quite a few. [url=http://stackoverflow.com/questions/538056/jit-compiler-vs-offline-compilers/538107#538107]This SO post sums it up pretty well[/url].[/QUOTE]
Yeah, see, that doesn't go in the case of .NET, especially this:
[quote]JITters can optimize for the specific CPU and memory configuration in use on the actual hardware where the program happens to be executing. For example, many .NET applications will run in either 32-bit or 64-bit code, depending upon where they are JITted. On 64 bit hardware they will use more registers, memory, and a better instruction set.[/quote]
That's the biggest (if not only) 'advantage of JIT compilers'. However, as I said before, AOT-compiled assemblies are also optimized for the specific CPU and memory configuration in use on the actual hardware where the program happens to be compiled and will execute, in .NET. The AOT-compiled code is invalidated in favour of JIT whenever the environment changes.

[jA_cOp]

[QUOTE=arienh4;25132116]
That's the biggest (if not only) 'advantage of JIT compilers'. However, as I said before, AOT-compiled assemblies are also optimized for the specific CPU and memory configuration in use on the actual hardware where the program happens to be compiled and will execute, in .NET. The AOT-compiled code is invalidated in favour of JIT whenever the environment changes.[/QUOTE]

If not only? So you just chose to ignore the other reasons provided? The third optimization mentioned in particular is known to be extremely successful.

Also, just because you AOT-compile with one system in mind doesn't mean that the executable will only run on that system, it's not common to see programs distributed in a broad array of versions to accommodate different configurations. The system-specific optimizations an AOT-compiler gains aren't nearly as versatile as those a JIT-compiler gains, making it a really minor advantage for AOT and a huge advantage for JIT. Most system-specific optimizations are related to use of registers and special instructions, neither of which requires a lot of time.

I claimed that the JIT compiler produces better code than doing AOT and you disagreed, but there's still no actual statistics to support either (like benchmarks).

[arienh4]

[QUOTE=jA_cOp;25132771]If not only? So you just chose to ignore the other reasons provided? The third optimization mentioned in particular is known to be extremely successful.

Also, just because you AOT-compile with one system in mind doesn't mean that the executable will only run on that system, it's not common to see programs distributed in a broad array of versions to accommodate different configurations. The system-specific optimizations an AOT-compiler gains aren't nearly as versatile as those a JIT-compiler gains, making it a really minor advantage for AOT and a huge advantage for JIT. Most system-specific optimizations are related to use of registers and special instructions, neither of which requires a lot of time.

I claimed that the JIT compiler produces better code than doing AOT and you disagreed, but there's still no actual statistics to support either (like benchmarks).[/QUOTE]
I'm talking about how the .NET AOT compiler works.

"Also, just because you AOT-compile with one system in mind doesn't mean that the executable will only run on that system"

For .NET, yes, it does. Simple as that.

I probably should've made that more clear, but the second advantage is the only one the .NET compiler makes use of, so that's the only one I mentioned. I for one believed this argument was started talking about .NET, not about JIT compilers in general.

[jA_cOp]

[QUOTE=arienh4;25132875]
For .NET, yes, it does. Simple as that.[/QUOTE]

It only reverts to JIT when the targeted environment is incompatible with the current environment.

[QUOTE=arienh4;25132875]I probably should've made that more clear, but the second advantage is the only one the .NET compiler makes use of[/QUOTE]

The .NET JIT compiler does [I]all[/I] of the mentioned optimizations in one form or another. The first point is very broad, but .NET does do runtime flow analysis and profiling. For example, the virtual dispatch optimization is only done after profiling has identified the dispatching function as "hot" enough.

AOT-compilers have to do with static analysis, and I somehow doubt NGEN does expensive static flow analysis.

[arienh4]

[QUOTE=jA_cOp;25133291]It only reverts to JIT when the targeted environment is incompatible with the current environment.

The .NET JIT compiler does [I]all[/I] of the mentioned optimizations in one form or another. The first point is very broad, but .NET does do runtime flow analysis and profiling. For example, the virtual dispatch optimization is only done after profiling has identified the dispatching function as "hot" enough.

AOT-compilers have to do with static analysis, and I somehow doubt NGEN does expensive static flow analysis.[/QUOTE]
All I'm saying is that you somehow got the idea that AOT is worse than JIT. It might be equal, but it's not worse. Try clearing your GAC and see how fast your .NET applications run.

[jA_cOp]

[QUOTE=arienh4;25133339]All I'm saying is that you somehow got the idea that AOT is worse than JIT.[/QUOTE]

I'm saying that JIT compilers have more possibilities than AOT compilers, even under time restrictions. A lot of programs will run a lot faster AOT-compiled simply because the JIT overhead does not pay off.

[QUOTE=arienh4;25133339]It might be equal, but it's not worse.[/QUOTE]

What kind of rhetoric is this? They're completely different and there's no "better" or "worse", but there's a "can produce better code". What matters is whether the process of JIT'ing is worth it and the quality of the JIT compiler versus the AOT compiler. In .NET's case, JIT is the default compilation model and the one that produces the best code. But AOT compilation is still provided when the considerable JIT overhead is not wanted and other edge cases.

[QUOTE=arienh4;25133339]Try clearing your GAC and see how fast your .NET applications run.[/QUOTE]

Again, this is because of the JIT compilation overhead; I only claimed the JIT compiler produces better code.

[neos300]

data
int yo 5+5
end

thread main
yo += 5
motor.mov(OUT_BC, 100)
waitms(4000)
motor.mov(OUT_BC, -100)
waitms(4000)
motor.stop(OUT_BC)
end

SUCESS! (This time for real)

dseg segment
yo sdword 5+5
dseg ends
thread main
add yo, yo, 5
OnFwd(OUT_BC, 100)
wait 4000
OnFwd(OUT_BC, -100)
wait 4000
Off(OUT_BC)
endt

[Chandler]

Currently working on the syntax for my language (I'd written it out before but I'm changing it now, and actually going to start development on it)

So far everything seems to be in working out pretty well. Here's a sample of a vector3 class with generics

import math

namespace math:

class vector3[T]:

    /* constructors */
    def new(none): self.x = self.y = self.z = 0 end
    def new(value: const ref T): self.x = self.y = self.z = value end
    def new(x, y, z: const ref T): 
        self.x = x
        self.y = y
        self.z = z
    end

    def move(move: const mov vector3[T]): 
        self.x = move.x
        self.y = move.y
        self.z = move.z
    end

    def copy(copy: const ref vector3[T]): 
        self.x = copy.x
        self.y = copy.y
        self.z = copy.z
    end

    /* methods */
    def normalize(none):
        value := cast[T](1.0 / self.length)
        self.x *= value
        self.y *= value
        self.z *= value
    end

    def all(value: const ref T): self.x = self.y = self.z = value end
    def one(none): self.x = self.y = self.z = cast[T](1) end
    def zero(none): self.x = self.y = self.z = 0 end

    /* operators */
    def is(right: const ref vector3[T]): 
        self.x is right.x and self.y is right.y and self.z is right.z
    end

    /* properties */
    x, y, z: T with
        get: default end
        set: default end
    end

    length_squared: const ref T with
        get: (self.x * self.x) + (self.y * self.y) + (self.z * self.z) end
    end

    length: const ref T with
        get: sqrt(self.length_squared) end
    end

end /* namespace math */

Also, since this doesn't show off how one would use pointers, here's what the default main declaration looks like

def main(args: const array[@char]) -> int: 0 end

[neos300]

The new fad is languages.

[ZeekyHBomb]

[QUOTE=Chandler;25134229]Currently working on the syntax for my language (I'd written it out before but I'm changing it now, and actually going to start development on it)

So far everything seems to be in working out pretty well. Here's a sample of a vector3 class with generics

import math

namespace math:

class vector3[T]:

    /* constructors */
    def new(none): self.x = self.y = self.z = 0 end
    def new(value: const ref T): self.x = self.y = self.z = value end
    def new(x, y, z: const ref T): 
        self.x = x
        self.y = y
        self.z = z
    end

    def move(move: const mov vector3[T]): 
        self.x = move.x
        self.y = move.y
        self.z = move.z
    end

    def copy(copy: const ref vector3[T]): 
        self.x = copy.x
        self.y = copy.y
        self.z = copy.z
    end

    /* methods */
    def normalize(none):
        value := cast[T](1.0 / self.length)
        self.x *= value
        self.y *= value
        self.z *= value
    end

    def all(value: const ref T): self.x = self.y = self.z = value end
    def one(none): self.x = self.y = self.z = cast[T](1) end
    def zero(none): self.x = self.y = self.z = 0 end

    /* operators */
    def is(right: const ref vector3[T]): 
        self.x is right.x and self.y is right.y and self.z is right.z
    end

    /* properties */
    x, y, z: T with
        get: default end
        set: default end
    end

    length_squared: const ref T with
        get: (self.x * self.x) + (self.y * self.y) + (self.z * self.z) end
    end

    length: const ref T with
        get: sqrt(self.length_squared) end
    end

end /* namespace math */

Also, since this doesn't show off how one would use pointers, here's what the default main declaration looks like

def main(args: const array[@char]) -> int: 0 end

[/QUOTE]

I find the combination of ':' for starting a scope and 'end' for ending it a little weird.
Also, for comparison you have the word 'is', but other arithmetic operators are their respective signs. I might just be too used to C++ though.

And what is the 'mov' keyword for arguments? I didn't quite get the move-method as well. Looks just like the copy-method to me :S

When accessing member-data, is 'self.' required?

Does it support inheritance? If so, what is the syntax for creating overridable methods, or are all functions overridable by default? And how do you call the base constructor?

What is the function-name for a destructor?

Can you also have private and protected fields?

[editline]09:26PM[/editline]
[QUOTE=ZeekyHBomb;25134600]What is the function-name for a destructor?[/QUOTE]
Is it old? :P

[esalaka]

[QUOTE=neos300;25134271]The new fad is languages.[/QUOTE]

Do we need a new WAYWO comic, then?

[CarlBooth]

[QUOTE=esalaka;25134708]Do we need a new WAYWO comic, then?[/QUOTE]

[IMG]http://i54.tinypic.com/140gmqe.jpg[/IMG]

It's #4 on the NYT best sellers list.

[pikzen]

:golfclap:

[Chandler]

[QUOTE=ZeekyHBomb;25134600]I find the combination of ':' for starting a scope and 'end' for ending it a little weird.
[/QUOTE]

I understand where you are coming from. The reason the "end" is there is because I didn't want to force Python style indenting on people, but I find the use of a whole keyword to be unnecessary just to enter a block

[QUOTE=ZeekyHBomb;25134600]
Also, for comparison you have the word 'is', but other arithmetic operators are their respective signs. I might just be too used to C++ though.
[/QUOTE]

The "is" is done because it completely removes the chance of an "if x = 7" error. In addition, I'm when you use "==" you're not performing arithmetic, you're performing boolean logic :)

[QUOTE=ZeekyHBomb;25134600]
And what is the 'mov' keyword for arguments? I didn't quite get the move-method as well. Looks just like the copy-method to me :S
[/QUOTE]

This is used for "moving" the contents of an object in memory. It lines up 1 : 1 with the new C++ move operator (const T&& x), in that you're not making a copy, but rather moving all of the contents from one object to the other. In languages that don't support this type of memory modification, it'll be treated as a copy. (Of note: originally this language was going to translate to C++ only, but it'll actually output all the data in YAML format, allowing multiple backends for translation to different languages, such as D, C++, C, ILASM, or LLVM IR)

[QUOTE=ZeekyHBomb;25134600]
When accessing member-data, is 'self.' required?
[/QUOTE]

Yes. One of the primary paradigms of this language is you must be explicit when accessing data.

[QUOTE=ZeekyHBomb;25134600]
Does it support inheritance? If so, what is the syntax for creating overridable methods, or are all functions overridable by default? And how do you call the base constructor?
[/QUOTE]

Yes it does. It was not shown here because vector3[T] is effectively a standalone. You would use inheritance like so:

class ZeekysObject(ChandlersObject): end

Of note, the inheritance in this language does NOT support multiple inheritance.

By default all methods in a class are overridable, so merely redefining the underlying method in the child class will do. However, private (the keyword used is local) methods cannot be overriden or virtual. If you want a public method that is not overridable, you would prefix it with "pure"

pure def no_override(none): end

To make a class non inheritable you would do the same with class (pure class)
The base constructor can be called by using "super.new()".

[QUOTE=ZeekyHBomb;25134600]
What is the function-name for a destructor?
[/quote]

The keyword and method name are "del"

[QUOTE=ZeekyHBomb;25134600]
Can you also have private and protected fields?
[/quote]

Yes. prefixing a method declaration with "local" or "guard" will have the intended effect.

Of note: properties cannot be local, they can only be protected, or public (which is their state by default)

Like I've stated though I'm still fixing the syntax, so there may be changes as to how the language works. :)

[arienh4]

[QUOTE=jA_cOp;25133502]I'm saying that JIT compilers have more possibilities than AOT compilers, even under time restrictions. A lot of programs will run a lot faster AOT-compiled simply because the JIT overhead does not pay off.

What kind of rhetoric is this? They're completely different and there's no "better" or "worse", but there's a "can produce better code". What matters is whether the process of JIT'ing is worth it and the quality of the JIT compiler versus the AOT compiler. In .NET's case, JIT is the default compilation model and the one that produces the best code. But AOT compilation is still provided when the considerable JIT overhead is not wanted and other edge cases.

Again, this is because of the JIT compilation overhead; I only claimed the JIT compiler produces better code.[/QUOTE]
JIT is the default compilation model, but it does not create better code. Why should it? AOT has much more time to do more expensive optimizations which would be too intensive for JIT.

And I'm claiming it doesn't. In certain cases, when a program is meant to run quite long, there might be a slight performance advantage when using JIT, but this can be mitigated by using hard binding.

[jA_cOp]

[QUOTE=arienh4;25135672]JIT is the default compilation model, but it does not create better code. Why should it?[/QUOTE]

Because it has more information available at compile-time, enabling an entire new world of available optimizations. You keep ignoring the arguments for JIT producing better code and keep reiterating that AOT compilation has time to do expensive optimizations. Most optimizations aren't expensive, and most expensive optimizations are very rarely implemented due to their complexity (like optimizations requiring static flow analysis).

[noctune9]

[QUOTE=arienh4;25135672]JIT is the default compilation model, but it does not create better code. Why should it? AOT has much more time to do more expensive optimizations which would be too intensive for JIT.

And I'm claiming it doesn't. In certain cases, when a program is meant to run quite long, there might be a slight performance advantage when using JIT, but this can be mitigated by using hard binding.[/QUOTE]

I remember hearing something about if the JIT compiler already had full code access security, it can skip certain security checks.

Also, Microsoft themselves say on their NGEN page that it is only possible to determine if AOT is actually beneficial with testing.

[Loli]

Any New Content? Or is this just a discussion now?

[Quarternions]

Discussion and one awesome thingie from r4nk

in this post : [url]http://www.facepunch.com/showpost.php?p=25126421&postcount=762[/url]

[gparent]

[QUOTE=noctune9;25136613]Also, Microsoft themselves say on their NGEN page that it is only possible to determine if AOT is actually beneficial with testing.[/QUOTE]
Yep, and this is true of most optimization. Profile, optimize, profile, release.

[Overv]

I just implemented all of the functions of GLU I used to my own Matrix class, except glUnProject. Calculating the inverse matrix is a bitch.

[ROBO_DONUT]

[QUOTE=Overv;25137964]I just implemented all of the functions of GLU I used to my own Matrix class, except glUnProject. Calculating the inverse matrix is a bitch.[/QUOTE]
I wrote code to do this a while back, and I'm fairly sure I still have it. I used it in my old game engine to calculate the view frustum for frustum culling. Yes, calculating a general matrix inverse is total overkill for that purpose. Now you know why my engine failed so hard.

I could post it if you think it would be useful, but it's difficult to read, full of SSE intrinsics, and probably pretty broken.

[inzuki]

[QUOTE=CoolPhase;25125872]You should call it Left [B]2 D[/B]ie (Get it? :q:).[/QUOTE]

Oh you :3:

Anyways, I've progressed on the game so far. I added HUD icons for the primary and secondary weapons slots, as well as the current ammo it holds and an icon for what weapon it is.

I even added animations! :buddy: (thankfully they weren't troublesome. But it did get confusing creating the images for them.)

I'll post a video soon, but I don't want to spam this thread with my game :v:

I'll at least post a screenshot:

[img]http://i51.tinypic.com/hu5dec.png[/img]

Also, this game will be very easy to create texture packs for. So if you hate the current art as much as I do (I suck at pixel art), you can create your own.

[CarlBooth]

[QUOTE=The Inzuki;25139342]I'll post a video soon, but I don't want to spam this thread with my game :v:[/QUOTE]

Keep posting, it's looking great.