<InPhase>
For the record, I spoke often about how much I wanted you to come back. :)
<InPhase>
Workflows approved.
<ochafik>
Hehe, thanks a lot! It's been a hectic few (many) months, I'm glad to be back :-) Hope I didn't miss too much
<InPhase>
ochafik: Just yesterday peepsalot with an assist from me managed to squeeze 21% improvement out of the heavy Nef3 designs by altering the most heavily used routines in CGAL. So these performance issues are fresh in mind.
<ochafik>
Ooh, exciting!!
<InPhase>
I need yet to wake my brain up enough to review the rest of that code.
<ochafik>
Haha, is it full of kernel abstractions? My CGAL memories are extremely fuzzy now :-D
<ochafik>
(aaaaand... will have to test things with CGAL 5.3 now I guess)
<InPhase>
The thing I did was swap a giant math-major determinant with a physics-major dot and cross product, then remove all the temporary object creation with in-place += *= etc operations. peepsalot then beefed up those +=, *= etc operations (which I need to look over yet), and in total it cut allocations by 25% and runtime by 21%.
<InPhase>
peepsalot spotted the opportunity following a custom malloc insertion which gave memory profiling as a bonus, and it appeared the amount of allocations on those rationals is insane. :)
<InPhase>
peepsalot: Why this change? const Gmpq& operator+() const;
<peepsalot>
it actualy reduced the allocation count by 42%, but they were skewed towards smaller allocs, so the total bytes of allocation was reduced about 25%
<InPhase>
peepsalot: There's no utility in anything other than grabbing the value, and RVO should kick in if it's just Gmpq.
<InPhase>
Assuming optimization is turned on anyway.
<InPhase>
peepsalot: And that might be UB that way.
<peepsalot>
did you see the function body? it was explicitly creating a new object before
<peepsalot>
that's unary +, its a noop
<ochafik>
InPhase: sounds awesome! is the code in a branch I can look at? (tomorrow... going to sleep now)
<peepsalot>
also a const member function so i don't see how RVO on *this would work
<peepsalot>
its a pointless operator anyways, i wouldn't be surprised if its not called anywhere
<InPhase>
peepsalot: Oh...
<InPhase>
Unary op is so stupid to implement I didn't even notice the empty ()...
<InPhase>
Allocating at all in a comparator feels wrong. And I hope those .mpz() and .mpq() calls return storage and don't allocate...
<peepsalot>
InPhase: which line are you looking at?
<InPhase>
The ones you #if 0'd out apparently.
<peepsalot>
and mpz() and mpq() just return the reference
<InPhase>
"<InPhase> I need yet to wake my brain up enough to review the rest of that code." Advance warning was given. ;)
<peepsalot>
it is maybe more clear as this->mpq() but its a member function
<peepsalot>
yeah those ops were weird because Gmpz doesn't define anything for long long (and on 64bit at least, long long == long anyways afaik)
ziggurat_ has quit [Read error: Connection reset by peer]
ziggurat_ has joined #openscad
<peepsalot>
ohh, wait i think i just realized why i was getting an error. because the Gmpz operators that it called out to were defined later in the file
<InPhase>
long long is a different type on some platforms, even if the same size.
<InPhase>
Those types are junk and should be banned in favor of uint32_t etc.
<InPhase>
But this change you cannot make here.
<InPhase>
From the C++20 standard, that I got good at searching thanks to the rules lawyers in #C++. "The operand of the unary + operator shall have arithmetic, unscoped enumeration, or pointer type and the result is the value of the argument."
<InPhase>
So I think you cannot make it a const lvalue.
<InPhase>
I think the expectation is that it makes a separate object.
<InPhase>
As you said, it's probably not used anywhere. But I think you can't make that change.
<peepsalot>
i don't even know what that means, shall have arithmetic? is arithmetic a type?
<InPhase>
"Integral and floating-point types are collectively called arithmetic types"
<peepsalot>
it doesn't say anything about the type of the result though? isn't the "operand" the input, aka this?
<InPhase>
Well the section on operator overloading does not impose any restrictions I suppose.
<InPhase>
(In the standard.)
<InPhase>
It also does not specify any lack of restrictions. Also, I hate the structure of this standard.
<InPhase>
That cppreference page interprets that section of the standard as only applying to built-in types, although the standard definitely does not say that anywhere I can see. *shrug*
snakedGT has quit [Ping timeout: 268 seconds]
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
<InPhase>
peepsalot: So I see some references to mpq_add_si on the Internet, but I can't find it in the main manuals... Did you try using this?
ochafik has quit [Ping timeout: 265 seconds]
<peepsalot>
no, didn't try any functions not mentioned in the manual
<InPhase>
I suppose it's not in the gmp.h header. Perhaps people added it to some alternate versions.
snaked has joined #openscad
ochafik has joined #openscad
<InPhase>
Oh I see. I think that's not possible to calculate without an allocation, which is probably why it's missing.
<InPhase>
I think you'd need to at least allocate one mpz, so they leave it out.
<peepsalot>
gmp internals use "scratch space" in a lot of places, with alloca which goes on the stack i think
<InPhase>
i.e., multiply by the numerator mpz, then canonicalize.
<InPhase>
And identically for the other sizes, and for division with denominator instead of numerator.
ochafik has quit [Remote host closed the connection]
<peepsalot>
yeah, seems like it could be an ok optimization. just would need to handle cases where !unique()
<InPhase>
Right.
<InPhase>
I tried hard. I have no other remaining critiques other than that optimization possibility.
arebil has joined #openscad
ochafik has joined #openscad
<peepsalot>
InPhase: any opinion what should be done about the long long operators? none of gmp native functions operate on long long and they we defined for Gmpq, but not Gmpz, so i'm not sure if there's even any reason for them to exist
<peepsalot>
like this whole line in Gmpq class def inheritance: , boost::ordered_field_operators2< Gmpq, long long
ochafik has quit [Ping timeout: 245 seconds]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<InPhase>
peepsalot: I think it's MSVC that treats long long as a separate type, so this was probably inserted by a Windows programmer attempting to be meticulous and include them all.
<dalias>
?
<dalias>
what do you mean by separate type?
<InPhase>
There might also be some embedded systems still out there treating long int as 32-bit and long long int as 64-bit.
<dalias>
long long is not the same as any other type
<dalias>
even if long is 64-bit, long and long long are different types
<teepee>
yeah, changed password earlier today, they can keep the old one :)
<teepee>
very misleading link tho
<teepee>
title says "Thingiverse Data Leak Affects 228,000 Subscribers" - slight difference to 25 million
<teepee>
but a bit more believable
<teepee>
reading that sounds like thingiverse is actually run by a couple of interns who are in office only once a week :/
<teepee>
matches the rumor it's running on a cluster of raspis, but I'm mostly sure that's just nonsense as the ip address resolves to google cloud platform ;-)
<dalias>
it's run by a company that bought it to sabotage hobbyist/non-$50k-printer 3d printing
<dalias>
(stratasys)
<dalias>
the same ones who held and enforced a silly patent on the basic concept of fdm, setting the whole industry back 2 decades
ndnihil is now known as nihil
nihil is now known as ndnihil
<InPhase>
I see how that "go as cheap as possible on the website for a few years" strategy is working out for them.
ochafik has joined #openscad
<ndnihil>
fucking thingiturd
<ndnihil>
one day, I'll finish my replacement for it
<ndnihil>
that'll show them
<ndnihil>
from back when they tried to claim rights to the models people uploaded
<InPhase>
So does this mean everyone should be changing their thingiverse password? Because normally you hear about this from the site first.
<dalias>
nobody's really gotten the concept for how such a site should work right
<dalias>
like really github is the right place for it, except not having the right indexing and searchability
<dalias>
(but it has the things you need -- file history, issue reports with comments, etc. -- that thingiverse and similar don't have)
<teepee>
I linked the ThingNetwork idea, but that had not enough support
<dalias>
and thingiverse's search is broken anyway :/
<dalias>
thangs is some data mining ML startup that wants your models to train their model
<dalias>
mmf is the most decent one i've seen targetinging creators of 3d models but resin-oriented & decorative models dominate the content
<dalias>
lots of nearly unprintable for fdm or at least have moderate design problems like wrong orientation, no bed adhesion surface (non-flat bottom), poor structural integrity, etc
<InPhase>
Customizer integration is the most important thing thingiverse had I think.
<InPhase>
Enable customizer on a design, and activity skyrocketed. People really wanted to use it.
<dalias>
:)
<teepee>
that and a huge number of people uploading stuff
arebil has joined #openscad
<Scopeuk>
running something as a thin shim ontop of github could work
<Scopeuk>
it does already have many of the features
<Scopeuk>
would possibly need to resolve the not all 3d modelers are software developers issue though
<Scopeuk>
just creating a repository and uploading could be intimidating for a newbie
<Scopeuk>
i suppose bonus points if you can add some base level ci that checks for "clean" g-code generation through a few common slicers
<Scopeuk>
automated printability checks are hard however
<dalias>
*nod*
<dalias>
i'd actually be okay with something thing thingiverse but designed for easy integration with github or other git hosting
<dalias>
where you can have it pull from your README.md or whatever rather than having to do your own editing of the description etc on the site with no history/version control
<dalias>
which i utterly hate
<dalias>
like that's the part i dread of uploading something to thingiverse
<Scopeuk>
generating a thingiverse like interface from a specific git structue should be fairly simple
<Scopeuk>
some specific readme with tags, a gallery folder and a models folder
<teepee>
yeah, fabfabbers worked that way IIRC, that's a useful solution, maybe cadhub will have that soon-ish too, we'll see :)
<Scopeuk>
I'm not familiar with that one
<teepee>
would be great to have something decentralized, but that's probably quite some extra work
<Scopeuk>
decentalised data is easy, decetralised searched and syncronised comments is hard
<teepee>
who knows, maybe mediagoblin will work at some point :)
<teepee>
not sure if that supports federation or global search or anything like that
<teepee>
oh, neat, looks like that's getting some development lately
<InPhase>
Scopeuk: git approaches also only work for OpenSCAD or the other less awesome programmatic approaches. All those tinkercad type designs do not git well.
<InPhase>
Although I would sleep okay at night if the leading 3D printing model site ended up pushing everybody to OpenSCAD. :)
<Scopeuk>
InPhase I would agree they don't work as well
<Scopeuk>
but in terms of just getting a file, and being able to update it in place binary files work also
<Scopeuk>
with git and the like
<Scopeuk>
obviously you cant difference etc like you can with a textual language
<Scopeuk>
certainly you would be no worse off than how thingiverse works (when it does)
<InPhase>
A nice site would maybe git in the background, such that all you do is upload new versions of files, or rename files on the website, and it does the git magic for you. Then direct git access is off to the side as an advanced feature.
<Scopeuk>
that was what I was thinking by a thin shim ontop of github
<InPhase>
Where perhaps by default there is no support for branches or complexities like that. I think that's too much for most.
<Scopeuk>
create a 3d model specific interface wit ha known structue in git
<Scopeuk>
agreed, and in many cases unrequired
<InPhase>
It would then be trivial to dual-host on git and said site, by just synchronizing repositories, if you already have the git skills.
<Scopeuk>
yes, I was thinking comments etc might be possible through some existing git hub features
<Scopeuk>
but yes a simple front end with open known storage would be great
<Scopeuk>
if stuff can be easily exfiltrated to antoher system things can easily move if something better comes along or if something fails
<Scopeuk>
might be a bit utopian though, web services do rather like their data prisoner lock in
<InPhase>
Easy port out, easy port in, can appeal to the right starter crowd.
<Scopeuk>
the only question is if that crowd is big enough to start a mass move
qeed has joined #openscad
<InPhase>
Scopeuk: Yeah... I often know how to design tools that will make people's lives much easier. I acknowledge up front that driving the masses around is not my area of expertise though.
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
<Scopeuk>
To some extent i think the way to work through that is to get someone out of neiche (friend child/partner etc) and ask them to try and do something and see where they try and go
ochafik has quit [Remote host closed the connection]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
ochafik has joined #openscad
ochafik has quit [Read error: Connection reset by peer]