search

Dadido3 / PB-Optimizer

GNU General Public License v3.0
3 stars 1 forks source link

Missing AppData Files #2

Closed tajmone closed 5 years ago

tajmone commented 5 years ago

Hi @Dadido3,

I realized that this tool tries to access some ASM assets from the AppData folder, which are not included in the project:

Main\Path_AppData = Helper::SHGetFolderPath(#CSIDL_APPDATA) + "/D3/PB-Optimizer/"

...

If Filename
  CopyFile(Filename, Main\Path_AppData + "Latest_Original.asm")
Else

Any chance you could include these test/sample files into the project?

I guess these are some test files, but they would be useful as a starting point to study your project.

I've been visiting thir repo many times in the last year, hoping its development would carry on, but it looks like it hasn't been active for quite a while. It's a pity, it was a really promising project, so I'm now trying to get a better understanding of how it works, and see if I can contribute to it.

Any chance you'll resume working on this project in the future?

tajmone commented 5 years ago

Thanks for the tweaks that allow using the local test file!

Dadido3 commented 5 years ago

Hi,

Latest_Original.asm is created when you replace PB's fasm executable with the optimizer executable, and then just do a normal compile with PB. But as the software isn't in the state to be hooked into compilers chain yet, i've just added an example assembly file. Just as a note, the test.asm file isn't the assembly of test.pb, i just copied that assembly file from my AppData folder, which happens to be some other program i tested with.

Regarding if i continue to work on this project:

There are a lot of things that need to be addressed until this optimizer gets into a usable state. It's not even the optimizing that's problematic (Even though that's a really complex topic on its own), but the sparse information you get from the assembly output. The optimizer has to do a lot of unnecessary guesswork, like calulating stack pointer offsets, determining the number of parameters of a function, and so on.

And even if the optimizer would have access to the compilers inner data structures (Or is being built into the compiler), it couldn't optimize everything. For example, the optimizer wouldn't know if some variable needs to be accessible across threads, as PureBasic doesn't have a volatile keyword for variables.

Apart from the use to optimize PureBasic applications it's nice to learn how assembly works with a project like this. One reason why i started working on this was to dig deeper into x86 and its quirks, and it has helped me to understand x86 more. (To the point to see, that a project like this is infeasible this way) If you really need the speed, use inline assembly in PB where it matters, or use a different language. (Not saying PureBasic is unusable, it's still pretty fast, lightweight and easy to use. As long as you don't write computational expensive loops and expect the compiler to optimize them well, which it doesn't. In which it is comparable to C, but with -O0 set)

I'm gonna close that issue, but you can still reply if you want.