Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Janos95
@Janos95
"echo "#include <algorithm>" | gcc-head -std=c++11 -P -E -x c++ - | wc -l" returns 11765
while
"echo "#include <algorithm>" | gcc-head -std=c++20 -P -E -x c++ - | wc -l" returns a whopping 45222
compiling an empty file including the algorithm header takes 0.15 sec (with c++11) vs 0.9 sec (with c++20)
Vladimír Vondruš
@mosra
hah, i thought you'd compare that to gcc 9
Janos95
@Janos95
I chased the includes and it turns out that <algorithm> transitively includes <ranges> which is 30 loc and contains lots of template stuff
Vladimír Vondruš
@mosra
because this happened for gcc 10, so i expected improvements: https://twitter.com/wakomeup/status/1196097492456214529
#include <ranges> is a fireable offense, then
Janos95
@Janos95
yes I can live without <ranges> in largish projects, but abondoning std::sort etc is not really an options :/
Vladimír Vondruš
@mosra
damn, right
i was just about to ask what exactly do you need from there
isn't it in some utility / internal header on gcc? so i could do another Utility/StlMath.h "deshittifier" but for <algorithm>
personally even the 0.15 sec was too much for me and so <algorithm> is included almost nowhere in magnum
another option: don't use c++20 :D
Janos95
@Janos95
yes I think one can include 
#include <bits/stl_algobase.h>
#include <bits/stl_algo.h>
not sure about other platforms

another option: don't use c++20 :D

but I already changed all my enable_if's to requires clauses :laughing:

Janos95
@Janos95

personally even the 0.15 sec was too much for me and so <algorithm> is included almost nowhere in magnum

should I compare compile times?

Vladimír Vondruš
@mosra
of magnum? :D
Vladimír Vondruš
@mosra
you might need to force the -std in CMAKE_CXX_FLAGS, otherwise it'll use 11
Janos95
@Janos95
with DCMAKE_CXX_STANDARD=11 it is 17.43 seconds and with DCMAKE_CXX_STANDARD=20 it is 22.13 seconds. Very unscientific, average of two parallel debug compiles, but variance was quit low, about 0.5 seconds maybe.
but interestingly it is about 1.5 slower than my system gcc, maybe I messed up compiling gcc, so everything with a grain of salt.

you might need to force the -std in CMAKE_CXX_FLAGS, otherwise it'll use 11

ah ok, I'll check one moment.

Vladimír Vondruš
@mosra
wow, 17 seconds, that's better than i remember
Janos95
@Janos95
yeah it was parallel with 14 cores
Vladimír Vondruš
@mosra
ahah okay
people with fast machines
was it with all tests?
or just the libs
libs alone i remember were around 20 seconds last time i checked, on a 8-core machine
Janos95
@Janos95
ah no, no tests. Good point.
Vladimír Vondruš
@mosra
but nobody builds tests except for me, so without them it's the more realistic measurement
with tests it's about 850 ninja targets i'm at 90 seconds and it's getting unbearable
Janos95
@Janos95
a full build with all test takes 26 seconds on 14 cores, one of these newer amd processors will probably eat magnum for breakfast ;). On the other hand it's kind of a bummer if one is not able to work on a laptop anymore...
Vladimír Vondruš
@mosra
that's insane
here the tests take majority of build time
while in your case the extreme parallelism makes it 17 secs for the libs and just ~9 for the tests?
Burak Canik
@fauder

https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/packages/SystemUI/src/com/android/systemui/glwallpaper/ImageProcessHelper.java#129 wait actually what the fuck

...

Vladimír Vondruš
@mosra
:fire: :phone: :fire:
Janos95
@Janos95

while in your case the extreme parallelism makes it 17 secs for the libs and just ~9 for the tests?

no I cannot reproduce this. There must have been something wrong now its more like 17sec for magnum and 33sec for the tests. This is also a lot more reasonable comparing to your numbers :)

Burak Canik
@fauder
I should use a Renderbuffer instead of a Texture2D if I want the buffer to be MSAA'd right ?
Burak Canik
@fauder
Got it working with MSAA.
I wonder what is the equivalent of a renderbuffer in DirectX
https://computergraphics.stackexchange.com/a/4432
I should study this
Burak Canik
@fauder
A comment says: "Wow. They probably hire toughest minds in the world to make up most distinct names for same things." Lol, true dat.
Vladimír Vondruš
@mosra
renderbuffers are useless nowadays, just use a texture
they still make sense on old apis (webgl 1 / ES2) because there you can't have multisampled textures, or the texture formats can't be rendered to, but with modern gpus there's not really a reason to use anything else than a texture
Burak Canik
@fauder
Okay but there is the setStorageMultisampled() api for renderbuffers
Is there a similar one for Texture2D ?