<peepsalot>
linext: btw are you building the WASM yourself, or do you use artifacts from the build servers somehow?
<peepsalot>
linext: it looks like emscripten supports Link time optimization (LTO). i'm wondering if adding compile/link option "-flto" might help speed up the WASM runtime a bit
aiyion1 has joined #openscad
GNUmoon has joined #openscad
Junxter has joined #openscad
fling has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
fling has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
aiyion1 is now known as aiyion
ndnihil has quit [Ping timeout: 268 seconds]
gbruno has quit [Ping timeout: 255 seconds]
fling has quit [Remote host closed the connection]
fling has joined #openscad
ndnihil has joined #openscad
ndnihil has joined #openscad
ndnihil has quit [Changing host]
fling_ has joined #openscad
fling has quit [Ping timeout: 255 seconds]
fling_ is now known as fling
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
gbruno has joined #openscad
gbruno has quit [Changing host]
gbruno has joined #openscad
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
gbruno has quit [Ping timeout: 255 seconds]
ndnihil has quit [Ping timeout: 268 seconds]
gbruno has joined #openscad
gbruno has quit [Changing host]
gbruno has joined #openscad
ndnihil has joined #openscad
ndnihil has joined #openscad
ndnihil has quit [Changing host]
J1A8484921 is now known as J1A84
<J1A84>
why is "inf" treated as number? and can't be compared? x!=inf
ur5us has joined #openscad
castaway has joined #openscad
<Scopeuk>
J1A84 ieee744 floating point defines inf and -inf and the rules for the results of comparisons using them
<Scopeuk>
Ieee754**
siege has quit [Read error: Software caused connection abort]
siege has joined #openscad
<J1A84>
but if "inf" is a number i should be able to use x<inf or
<J1A84>
but inlike undef inf is just not recognized
<Scopeuk>
J1A84 I guess it's to limit name space polution but it may more simply be that it doesn't have a meaning in context, you are quite correct that there are time you may want it when writing libraries
<peepsalot>
"--closure 1" looks like another option that might be worth trying
<peepsalot>
sounds like that is mostly for reducing size, and may not affect runtime. but occasionally those can go hand in hand
<peepsalot>
linext: one last thing I would try for optimizing wasm, is if there are alternative malloc implementations
<peepsalot>
for example moving to mimalloc on desktop gave something like 40-80% speed increase. that's not applicable to WASM, but...
<peepsalot>
emscripten apparently has a builtin alternative malloc you can try with -s 'MALLOC="emmalloc"' sounds like its main purpose is for small code size, so may not help with speed, but could be worth a try
<peepsalot>
there may be other 3rd party malloc replacements for WASM
<peepsalot>
linext: were you able to see if runs any faster with that build?
<peepsalot>
teepee: btw, i ended up getting packaged up tests to work for windows.
<peepsalot>
teepee: I couldn't get cpack to create individual OpenSCAD / Tests archives, but I just made it so the ZIP contains both, while NSIS installer omits tests.
<peepsalot>
I just don't remember how the snapshot downloads on openscad.org are controlled, if there is anything that might need updating to work with my changes
fling has joined #openscad
<J1A84>
first i thought i could do this with twist and extrude but this is different https://pasteboard.co/U3Q6SieruXRO.png .. and whirls can be printed in spiral mode Ü
<linext>
with the -O3 and -flto, the render time was exactly the same
<InPhase>
Infinity is a defined value in IEEE-754. But it's still not a number.
<InPhase>
The term "number" has a specific meaning.
<InPhase>
Infinity is an abstract concept with some defined comparisons and rules, but these operate differently from numbers.
<J1A84>
and there is also -inf Ü
<InPhase>
Yes.
<J1A84>
and inf works with sign()
<InPhase>
All fine.
<J1A84>
so is_number (inf) is a bug
<J1A84>
inf also works in min / max
<linext>
peepsalot, what line gets --closure 1, and -s 'MALLOC="emmalloc" ?
<InPhase>
It seems that is_num goes way back to early days in the project.
<InPhase>
I haven't checked behavior in the old code, but possible the broken behavior on inf has existed for a long time.
<InPhase>
So here we have a case where an operation is mathematically invalid, has existed for more than a decade, and is even DOCUMENTED as doing the mathematically invalid thing.
<peepsalot>
only since 2019.05, but yes it is documented as such
<InPhase>
To change it we would have to decide to value backwards compatibility with the field of mathematics over backwards compatibility with past releases, and cross our fingers on the behavior being unutilized or rarely utilized given that it is a pretty fringe test to do.
<peepsalot>
linext: the same line 27 in the dockerfile where the comment says to "Add emscripten flags here". you can see other -s style options there already
<peepsalot>
linext: it looks like the "--closure 1" should go before any of the -s options, but no idea if that order really matters
<InPhase>
peepsalot: Is this one of those cases where git blame is just making up fake answers after I ignore enough revisions?
<InPhase>
Someone should really tweak how git blame behaves with that...
<InPhase>
It is blaming is_num on a 2011 commit that does not have is_num in it.
<InPhase>
I swear git is a terrible and broken tool sometimes.
<J1A84>
.. i thought about using accounts like "nobody" or "deleted" .. the git could blame "nobody"
<peepsalot>
linext: i'm actually not very sure about any of it though. that line in the dockerfile is like doing regex replacement of a pre-generated link command file. so that may be only affecting the link step?
<peepsalot>
with: target_compile_options(OpenSCAD PUBLIC "-O3 -flto -closure 1 [...]")
<peepsalot>
linext: if you can view the verbose build commands you should be able to verify if the flags are getting added properly
<peepsalot>
InPhase: I don't think I've run into an issue like that of completely incorrect blames
<peepsalot>
InPhase: how are you ignoring them? i usually use the github blame interface, and follow the "view blame before these changes" (or whatever that label text is)
<peepsalot>
VScode with gitlens also has a similar "view blame for prior changes", which uses the same icon as github
<linext>
yes, render time improved using --closure 1, and -s 'MALLOC="emmalloc"
<InPhase>
peepsalot: Which begs the question of why those lines are attributed to commits from before that when I ignore that commit.
<InPhase>
s/begs/raises/
<peepsalot>
linext: it is possible that the -O3 -flto is only being applied to the final link command, and not the individual compile commands? i think it needs to be on both
<linext>
ok
<peepsalot>
linext: are you able to see a build log with the full build command listing?
<linext>
i can send it to a file
<peepsalot>
InPhase: you might need to set git config option: blame.markUnblamableLines
<peepsalot>
i don't know how github/vscode does the "view blame prior to this change", but it seems like that is not at all the same as completely ignoring a revision
<peepsalot>
InPhase: the git blame man page explanation of --ignore-rev sounds like the more you ignore the more broken the results will be. I only set the one beautify commit from teepee to ignore, since that was mostly whitespace changes
<linext>
hmmm...
<linext>
not sure how to edit the DockerFile and/or CMakeLists.txt
<InPhase>
peepsalot: I suppose I could function with a git blame-before.
<peepsalot>
linext: how did you change the flags before without editing your Dockerfile?
<InPhase>
peepsalot: markUnblamableLines does not seem to perform any function.
<InPhase>
I tossed it in user level .gitconfig as [blame]\n markUnblamableLines = true
<peepsalot>
the man page also mentions blame.markIgnoredLines
<linext>
these two: line 7 as environment variable: export CXXFLAGS="-O3 --closure 1 -flto" && ...
<InPhase>
peepsalot: Oh, no, it does actually mark some lines as unblamable. It just marks the wrong ones.
<InPhase>
peepsalot: It's just complete nonsense data, rather than doing what it says.
<peepsalot>
not sure actually what the difference is between unblamable and ignoredlines
<peepsalot>
i would think that ignored lines are inherently unblamable, but idk
<InPhase>
There's really no logical way that a line can be blamed on a commit that doesn't have any part of that line in it. It's just unusably buggy.
<InPhase>
More support points for a new version system to dethrone git.
<InPhase>
I bet at the root of it is one of those problems with an algorithm performing complicated differencing analysis, such that git itself can't tell where a line actually came from.
<InPhase>
The man page says, "Lines that were changed or added by an ignored commit will be blamed on the previous commit that changed that line or nearby lines."
<InPhase>
But "nearby lines" must grow progressively worse.
<peepsalot>
linext: no, [...] was meant as "possibly put other options here"
teepee_ has joined #openscad
<peepsalot>
linext: like that -s MALLOC option
<peepsalot>
because I honestly don't know if those -s options count as regular compile options. i really don't know what the overall WASM build process looks like
<peepsalot>
linext: also in your line 84, i think the --closure needs two dashes but only has one.
teepee has quit [Quit: bye...]
teepee_ is now known as teepee
<oldlaptop>
InPhase: Maybe you want fossil.
<oldlaptop>
The world is not exactly short on version-control systems designed specifically to not be git, by people who don't like git (in much the same way as git was designed to not be cvs or svn by someone who doesn't like cvs or svn)
<oldlaptop>
(also wrong channel :| never mind that)
<linext>
hmm... build failed
<InPhase>
oldlaptop: Yeah, that might be a better system. It appears to be under sparse use, but sounds like a more sensible design at least from the top-level summary.
<InPhase>
oldlaptop: The real merits would be in the details, but perhaps I'll look those over more carefully later.
<oldlaptop>
the major uses are sqlite (for which it was designed) and tcl, so far as I'm aware
<oldlaptop>
netbsd maintains or maintained a fossil mirror, and AIUI discovered in the course of doing that that fossil doesn't really scale to something the size of netbsd :|
<teepee>
peepsalot: the download stuff is pulled via cron job reading the CircleCI API
<teepee>
downloading the artifacts and generating a json description file that is giving the website the info what's latest
<InPhase>
teepee: Well good. They recognize us as a downstream project looking for performance. :)
<peepsalot>
teepee: ah, ok
<peepsalot>
I put the tests in the .zip archive only, since they wouldn't be runnable from the default installer location under "Program Files" anyways
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
TheAssassin has quit [Remote host closed the connection]