1,460,995 events recorded by gharchive.org of which 1,460,995 were push events containing 1,919,074 commit messages that amount to 126,335,217 characters filtered with words.py@e23d022007... to these 29 messages:
Fixes Massive Radio Overtime, Implements a Spatial Grid System for Faster Searching Over Areas (#61422)
a month or two ago i realized that on master the reason why get_hearers_in_view() overtimes so much (ie one of our highest overtiming procs at highpop) is because when you transmit a radio signal over the common channel, it can take ~20 MILLISECONDS, which isnt good when 1. player verbs and commands usually execute after SendMaps processes for that tick, meaning they can execute AFTER the tick was supposed to start if master is overloaded and theres a lot of maptick 2. each of our server ticks are only 50 ms, so i started on optimizing this.
the main optimization was SSspatial_grid which allows searching through 15x15 spatial_grid_cell datums (one set for each z level) far faster than iterating over movables in view() to look for what you want. now all hearing sensitive movables in the 5x5 areas associated with each spatial_grid_cell datum are stored in the datum (so are client mobs). when you search for one of the stored "types" (hearable or client mob) in a radius around a center, it just needs to
iterate over the cell datums in range
add the content type you want from the datums to a list
subtract contents that arent in range, then contents not in line of sight
return the list
from benchmarks, this makes short range searches like what is used with radio code (it goes over every radio connected to a radio channel that can hear the signal then calls get_hearers_in_view() to search in the radios canhear_range which is at most 3) about 3-10 times faster depending on workload. the line of sight algorithm scales well with range but not very well if it has to check LOS to > 100 objects, which seems incredibly rare for this workload, the largest range any radio in the game searches through is only 3 tiles
the second optimization is to enforce complex setter vars for radios that removes them from the global radio list if they couldnt actually receive any radio transmissions from a given frequency in the first place.
the third optimization i did was massively reduce the number of hearables on the station by making hologram projectors not hear if dont have an active call/anything that would make them need hearing. so one of hte most common non player hearables that require view iteration to find is crossed out.
also implements a variation of an idea oranges had on how to speed up get_hearers_in_view() now that ive realized that view() cant be replicated by a raycasting algorithm. it distributes pregenerated abstract /mob/oranges_ear instances to all hearables in range such that theres at max one per turf and then iterates through only those mobs to take advantage of type-specific view() optimizations and just adds up the references in each one to create the list of hearing atoms, then puts the oranges_ear mobs back into nullspace. this is about 2x as fast as the get_hearers_in_view() on master
holy FUCK its fast. like really fucking fast. the only costly part of the radio transmission pipeline i dont touch is mob/living/Hear() which takes ~100 microseconds on live but searching through every radio in the world with get_hearers_in_radio_ranges() -> get_hearers_in_view() is much faster, as well as the filtering radios step
the spatial grid searching proc is about 36 microseconds/call at 10 range and 16 microseconds at 3 range in the captains office (relatively many hearables in view), the new get_hearers_in_view() was 4.16 times faster than get_hearers_in_view_old() at 10 range and 4.59 times faster at 3 range
SSspatial_grid could be used for a lot more things other than just radio and say code, i just didnt implement it. for example since the cells are datums you could get all cells in a radius then register for new objects entering them then activate when a player enters your radius. this is something that would require either very expensive view() calls or iterating over every player in the global list and calling get_dist() on them which isnt that expensive but is still worse than it needs to be
on normal get_hearers_in_view cost the new version that uses /mob/oranges_ear instances is about 2x faster than the old version, especially since the number of hearing sensitive movables has been brought down dramatically.
with get_hearers_in_view_oranges_ear() being the benchmark proc that implements this system and get_hearers_in_view() being a slightly optimized version of the version we have on master, get_hearers_in_view_as() being a more optimized version of the one we have on master, and get_hearers_in_LOS() being the raycasting version currently only used for radios because it cant replicate view()'s behavior perfectly.
Adds ItemSlot to Headset to take in Encryption Keys. On a side note: HOLY FUCKING SHIT THIS ACTUALLY WORKS, CAN I DO IT? DO I DARE DREAM? HOW FAR CAN MY SHITCODE TAKE ME? HOW FAR CAN I FAKE IT?
[MIRROR] Add Ethereal lungs to the limbgrower (#1611)
- Add Etheral lungs to the limbgrower (#62469)
Saturday morning, calm shift. I spend most of my time staring at CANARY waiting for an atmos alarm to pop up while I sit at the foyer hearing what random craziness Poly is spewing and wondering about the previous and more interesting shifts. When suddenly, an atmos alarm pops up at the Incinerator. "Fucks sake, I bet the other atmos are torching the place again..." I rush there expecting to fix a fire, but instead I find the start of something great...
The madman kidnapped an Ethereal to use as an organic Hydrogen farm, nothing I haven't seen before but... my hands start shaking, a spark of brilliance and potential in my eyes as I mumbled the words: "I always hear that organic things are healthier... so what if we throw the Electrolyzer away and instead, print Etheral lungs in the limbgrower and implant them on monkeys..." To our sadness, Ethereal lungs weren't added to the Ethereal disk design, this fixes that!
- Add Ethereal lungs to the limbgrower
Co-authored-by: GuillaumePrata [email protected]
[MIRROR] Reduces the move delay buffer to 1 tick, fixes "Flash stepping" (Is that what the kids are calling it?) [MDB IGNORE] (#10013)
- Reduces the move delay buffer to 1 tick (#63332)
We've got this delay buffer behavior Idea is basically, if we're just holding down the key, just keep adding to the old delay This way, fractional move delays make sense
Was added in this commit 491bdac
When it was added, movement was triggered by verbs sent by the client So we needed a big grace window to account for networking delay
Don't need that anymore cause we use keyLoop, so let's just cut it all the way down
Why? Because right now if you somehow manage to input a move afer move_delay is up but before the window runs out, you will be elidgable for a new move before you visually reach the tile
Got a dm from mothblocks about this last night, something about flash stepping? IDK I don't play here Seems silly though, let's sweep this up
Oh and mothblocks owes me a pizza, please add this to the commit history so it can be certified as a part of the blockchain
- Reduces the move delay buffer to 1 tick, fixes "Flash stepping" (Is that what the kids are calling it?)
Co-authored-by: LemonInTheDark [email protected]
Created Text For URL [thenationonlineng.net/ill-be-a-joy-giver-for-rest-of-my-life-burna-boy-vows/]
Created Text For URL [www.thisdaylive.com/index.php/2021/12/18/nancy-isime-my-dream-man-is-someone-on-the-same-page-with-me-spiritually-and-morally/]
Fix enum type definition pre-parsing for shcomp and dot/source
Parser limitations prevent shcomp or source from handling enum types correctly:
$ cat /tmp/colors.sh
enum Color_t=(red green blue orange yellow)
Color_t -A Colors=([foo]=red)
$ shcomp /tmp/colors.sh > /dev/null
/tmp/colors.sh: syntax error at line 2: `(' unexpected
$ source /tmp/colors.sh
/bin/ksh: source: syntax error: `(' unexpected
Yet, for types created using 'typeset -T', this works. This is done via a check_typedef() function that preliminarily adds the special declaration builtin at parse time, with details to be filled in later at execution time.
This hack will produce ugly undefined behaviour if the definition command creating that type built-in is then not actually run at execution time before the type built-in is accessed.
But the hack is necessary because we're dealing with a fundamental design flaw in the ksh language. Dynamically addable built-ins that change the syntactic parsing of the shell language on the fly are an absurdity that violates the separation between parsing and execution, which muddies the waters and creates the need for some kind of ugly hack to keep things like shcomp more or less working.
This commit extends that hack to support enum.
src/cmd/ksh93/sh/parse.c:
- check_typedef():
- Add 'intypeset' parameter that should be set to 1 for typeset and friends, 2 for enum.
- When processing enum arguments, use AST getopt(3) to skip over enum's options to find the name of the type to be defined. (getopt failed if we were running a -c script; deal with this by zeroing opt_info.index first.)
- item(): Update check_typedef() call, passing lexp->intypeset.
- simple(): Set lexp->intypeset to 2 when processing enum.
The rest of the changes are all to support the above and should be fairly obvious, except:
src/cmd/ksh93/bltins/enum.c:
- enuminfo(): Return on null pointer, avoiding a crash upon executing 'Type_t --man' if Type_t has not been fully defined due to the definition being pre-added at parse time but not executed. It's all still wrong, but a crash is worse.
Resolves: ksh93/ksh#256
Fix defining types conditionally and/or in subshells (re: 1dc18346)
This commit mitigates the effects of the hack explained in the referenced commit so that dummy built-in command nodes added by the parser for declaration/assignment purposes do not leak out into the execution level, except in a relatively harmless corner case.
Something like
if false; then
typeset -T Foo_t=(integer -i bar)
fi
will no longer leave a broken dummy Foo_t declaration command. The same applies to declaration commands created with enum.
The corner case remaining is:
$ ksh -c 'false && enum E_t=(a b c); E_t -a x=(b b a c)' ksh: E_t: not found
Since the 'enum' command is not executed, this should have thrown a syntax error on the 'E_t -a' declaration: ksh: syntax error at line 1: `(' unexpected
This is because the -c script is parsed entirely before being executed, so E_t is recognised as a declaration built-in at parse time. However, the 'not found' error shows that it was successfully eliminated at execution time, so the inconsistent state will no longer persist.
This fix now allows another fix to be effective as well: since built-ins do not know about virtual subshells, fork a virtual subshell into a real subshell before adding any built-ins.
src/cmd/ksh93/sh/parse.c:
-
Add a pair of functions, dcl_hactivate() and dcl_dehacktivate(), that (de)activate an internal declaration built-ins tree into which check_typedef() can pre-add dummy type declaration command nodes. A viewpath from the main built-ins tree to this internal tree is added, unifying the two for search purposes and causing new nodes to be added to the internal tree. When parsing is done, we close that viewpath. This hides those pre-added nodes at execution time. Since the parser is sometimes called recursively (e.g. for command substitutions), keep track of this and only activate and deactivate at the first level.
-
We also need to catch errors. This is done by setting libast's error_info.exit variable to a dcl_exit() function that tidies up and then passes control to the original (usually sh_exit()).
-
sh_cmd(): This is the most central function in the parser. You'd think it was sh_parse(), but $(modern)-form command substitutions use sh_dolparen() instead. Both call sh_cmd(). So let's simply add a dcl_hacktivate() call at the beginning and a dcl_deactivate() call at the end.
-
assign(): This function calls path_search(), which among many other things executes an FATH search, which may execute arbitrary code at parse time (!!!). So, regardless of recursion level, forcibly dehacktivate() to avoid those ugly parser side effects returning in that context.
src/cmd/ksh93/bltins/enum.c: b_enum():
- Fork a virtual subshell before adding a built-in.
src/cmd/ksh93/sh/xec.c: sh_exec():
- Fork a virtual subshell when detecting typeset's -T option.
Improves fix to ksh93/ksh#256
Multiparam config set (#9748)
We can now do: config set maxmemory 10m repl-backlog-size 5m
- Backup all relevant current values (via get).
- Run "verify" and "set" on everything, if we fail run "restore".
- Run "apply" on everything (optional optimization: skip functions already run). If we fail run "restore".
- Return success.
- Run set on everything in backup. If we fail log it and continue (this puts us in an undefined state but we decided it's better than the alternative of panicking). This indicates either a bug or some unsupported external state.
- Run apply on everything in backup (optimization: skip functions already run). If we fail log it (see comment above).
- Return error.
- Apply function are idempotent (have no effect if they are run more than once for the same config).
- No indication in set functions if we're reading the config or running from the
CONFIG SETcommand (removedupdateargument). - Set function should set some config variable and assume an (optional) apply function will use that
later to apply. If we know this setting can be safely applied immediately and can always be reverted
and doesn't depend on any other configuration we can apply immediately from within the set function
(and not store the setting anywhere). This is the case of this
dirconfig, for example, which has no apply function. No apply function is need also in the case that setting the variable in theserverstruct is all that needs to be done to make the configuration take effect. Note that the original concept ofupdate_fn, which received the old and new values was removed and replaced by the optional apply function. - Apply functions use settings written to the
serverstruct and don't receive any inputs. - I take care that for the generic (non-special) configs if there's no change I avoid calling the setter (possible optimization: avoid calling the apply function as well).
- Passing the same config parameter more than once to
config setwill fail. You can't doconfig set my-setting value1 my-setting value2.
Note that getting save in the context of the conf file parsing to work here as before was a pain.
The conf file supports an aggregate save definition, where each save line is added to the server's
save params. This is unlike any other line in the config file where each line overwrites any previous
configuration. Since we now support passing multiple save params in a single line (see top comments
about save in redis/redis#9644) we should deprecate the aggregate nature of
this config line and perhaps reduce this ugly code in the future.
Added a few new classes:
- AdjacencyMatrix: This is the real algorithm workhorse of what we are doing. I decided to model this problem as a co-occurrence matrix. This is an ordered co-occurrence matrix; but each pair is slid across, so even if a value has been flipped twice it's really only once with the way the Polymizer algorithm works. This class is constructed either by being passed a matrix and a value lookup. I probably could have used generics here, but decided it's chars because that's what this problem has. The class can also be constructed by getting some insertionRules. This is a PolyPair: (Char, Char), Char that I use to take the set of all available characters. Then create it into an index lookup map. This class also provides a lazy reverseLookup if needed. Really there are three methods: a) LookupCell value, updateCell Value and CountCooccurrences.
- Polimizer: This is the main class that knows how to parse the input for the problem. It creates the default state as well as the default adjacencyMatrix and the insertion rules. Then the main method that contains the algoirthm is the applyInsertionRulesOnce. This takes in a polymizer and iterates over the insertion map. For each value in the insertion map I lookup the current value for the Char, Char key. If there are no values we end for that element. If that element does has some alue there are three output: Left part of the pair and the insertion character and the insertion character, right part.. .Both those pairs add the value from the original Left, Right lookup. I also emit the negative value for that pair. Each iteration outputs three PolyPair -> Long... Due to the way insertion rules happen there could be duplicates in this list. To handle the duplicates to sum them up we iterate through the pairs -> Long and add them to the map. Updating values in this immutable map is effectively Constant based on scala documentation so it's pretty fast.
- PolyPair. This is just a helper container. I was getting sick of all the (Char, Char) and was hurting my brain. This helps my brain happier. It also ahs a toString override that made troubleshooting easier.
- ExtendedPOlymerization. Just reads in the input file and steps through it 40 times. This runs in subseconds.
Merge: Performance improvements.
This patchset brings some performance improvements and the addition of the LZO-RLE algorithm to the kernel, also usable in zram (yup, tested, works but LZ4 is still ok for us).
The main performance improvement is for SWAP space: the locking has changed and the swap cache is now split in 64MB trunks. This gives us a reduction of the median page fault latency of 375%, from 15uS to 4uS, and an improvement of 192% on the swap throughput (this includes "virtual" swap devices, like zRAM!). The real world user experience improvement of this on a mobile device is seen after a day or two of usage, where it usually starts losing just a little performance due to the large amount of apps kept open in background: now I cannot notice any more performance loss and the user experience is now basically the same as if the phone was in its first 2 hours of boot life.
Other performance improvements include, in short:
UDP v4/v6: 10% more performance on single RX queue
Userspace applications will be faster when checking running time of threads
2-5% improvements on heavy multipliers (yeah, not a lot, but was totally free...)
Improvements on rare conditions during sparsetruncate of about 0.3% to a
way more rare around 20% improvement (that's never gonna happen, but there
is no performance drop anywhere).
Tested on SoMC Tama Akatsuki RoW
This was taken from Repo: https://github.com/sonyxperiadev/kernel PR: 2039 ([2.3.2.r1.4] Performance improvements)
Signed-off-by: sweetyicecare [email protected] Signed-off-by: Jprimero15 [email protected]
Conflicts: mm/swapfile.c
'urgent' messages
Follow up on some old groundwork. For tty, if the core has designated a message as 'urgent', override any message suppression taking place because of ESC typed at the --More-- prompt. Right now, "You die" messages, feedback about having something stolen, feedback for "amorous demon" interaction (mainly in case of armor removal), and exploding a bag of holding are treated as urgent.
The "You die" case is already handled by a hack in top-line handling; I left that in place so the conversion of 3 or 4 pline("You die.") to custompline(URGENT_MESSAGE, "You die.") was redundant. There are probably various non-You_die messages which precede done() which should be marked urgent too.
Other interfaces might want to do something similar. And we ought to implement MSGTYPE=force or MSGTYPE=urgent to allow players to indicate other messages that they want have to override suppression. But I'm not intending to work on either of those. I mainly wanted to force the magic bag explosion message to be shown since a sequence of "You put into ." messages is a likely candidate for --More--ESC.
sched/core: Fix ttwu() race
Paul reported rcutorture occasionally hitting a NULL deref:
sched_ttwu_pending() ttwu_do_wakeup() check_preempt_curr() := check_preempt_wakeup() find_matching_se() is_same_group() if (se->cfs_rq == pse->cfs_rq) <-- BOOM
Debugging showed that this only appears to happen when we take the new code-path from commit:
2ebb17717550 ("sched/core: Offload wakee task activation if it the wakee is descheduling")
and only when @cpu == smp_processor_id(). Something which should not be possible, because p->on_cpu can only be true for remote tasks. Similarly, without the new code-path from commit:
c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu")
this would've unconditionally hit:
smp_cond_load_acquire(&p->on_cpu, !VAL);
and if: 'cpu == smp_processor_id() && p->on_cpu' is possible, this would result in an instant live-lock (with IRQs disabled), something that hasn't been reported.
The NULL deref can be explained however if the task_cpu(p) load at the beginning of try_to_wake_up() returns an old value, and this old value happens to be smp_processor_id(). Further assume that the p->on_cpu load accurately returns 1, it really is still running, just not here.
Then, when we enqueue the task locally, we can crash in exactly the observed manner because p->se.cfs_rq != rq->cfs_rq, because p's cfs_rq is from the wrong CPU, therefore we'll iterate into the non-existant parents and NULL deref.
The closest semi-plausible scenario I've managed to contrive is somewhat elaborate (then again, actual reproduction takes many CPU hours of rcutorture, so it can't be anything obvious):
X->cpu = 1
rq(1)->curr = X
CPU0 CPU1 CPU2
// switch away from X
LOCK rq(1)->lock
smp_mb__after_spinlock
dequeue_task(X)
X->on_rq = 9
switch_to(Z)
X->on_cpu = 0
UNLOCK rq(1)->lock
// migrate X to cpu 0
LOCK rq(1)->lock
dequeue_task(X)
set_task_cpu(X, 0)
X->cpu = 0
UNLOCK rq(1)->lock
LOCK rq(0)->lock
enqueue_task(X)
X->on_rq = 1
UNLOCK rq(0)->lock
// switch to X
LOCK rq(0)->lock
smp_mb__after_spinlock
switch_to(X)
X->on_cpu = 1
UNLOCK rq(0)->lock
// X goes sleep
X->state = TASK_UNINTERRUPTIBLE
smp_mb(); // wake X
ttwu()
LOCK X->pi_lock
smp_mb__after_spinlock
if (p->state)
cpu = X->cpu; // =? 1
smp_rmb()
// X calls schedule()
LOCK rq(0)->lock
smp_mb__after_spinlock
dequeue_task(X)
X->on_rq = 0
if (p->on_rq)
smp_rmb();
if (p->on_cpu && ttwu_queue_wakelist(..)) [*]
smp_cond_load_acquire(&p->on_cpu, !VAL)
cpu = select_task_rq(X, X->wake_cpu, ...)
if (X->cpu != cpu)
switch_to(Y)
X->on_cpu = 0
UNLOCK rq(0)->lock
However I'm having trouble convincing myself that's actually possible on x86_64 -- after all, every LOCK implies an smp_mb() there, so if ttwu observes ->state != RUNNING, it must also observe ->cpu != 1.
(Most of the previous ttwu() races were found on very large PowerPC)
Nevertheless, this fully explains the observed failure case.
Fix it by ordering the task_cpu(p) load after the p->on_cpu load, which is easy since nothing actually uses @cpu before this.
Fixes: c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") Reported-by: Paul E. McKenney [email protected] Tested-by: Paul E. McKenney [email protected] Signed-off-by: Peter Zijlstra (Intel) [email protected] Signed-off-by: Ingo Molnar [email protected] Link: https://lkml.kernel.org/r/[email protected] Change-Id: I40e0e01946eadb1701a4d06758e434591e5a5c92
[MIRROR] Nerfs the shit out of the felinid tail grab mood buff. (#1494)
- Nerfs the shit out of the felinid tail grab mood buff (#62768)
Mood controls your movespeed. Making Felinids objectively the best mood management race provided your metagame buddyfriend pulls your tail once every two minutes is insane, even as a meme.
A +5 mood buff was ridiculously good. This is better than the antag mood buff which is 4, equal to the cult buff for sacrificing which is 5, better than tripping balls, better than playing an arcade game and winning, better than the upgraded hug, equal with the best hug, and frankly one of the easiest best mood buffs you can get. And stacks with all the other ones.
- Nerfs the shit out of the felinid tail grab mood buff.
Co-authored-by: Iamgoofball [email protected]
[MIRROR] Nerfs the shit out of the negative sprayed with water mood event for Felinids (#1493)
- Nerfs the shit out of the negative sprayed with water mood event for Felinids (#62769)
Mood controls your movespeed. Making Felinids get their movespeed tanked because someone tried to fire extinguisher them is insane. Movespeed is the most important factor in SS13 when it comes to just about everything, it's how we punish people for damage after all.
A -5 mood is insanely punishing. It is equivalent to getting smitten by the gods, worse than a terrible noogie, worse than being bald, worse than literally throwing up all over yourself, worse than losing your family heirloom, and worse than having your eye stabbed out. This sucks for how easy it is to inflict on someone, especially considering the most common method of inflicting this is trying to fire extinguisher someone who's lit themselves on fire.
🆑 balance: Nerfs the felinid water spray moodlet /🆑
- Nerfs the shit out of the negative sprayed with water mood event for Felinids
Co-authored-by: Iamgoofball [email protected]
clocksource: Forgive repeated long-latency watchdog clocksource reads
Currently, the clocksource watchdog reacts to repeated long-latency clocksource reads by marking that clocksource unstable on the theory that these long-latency reads are a sign of a serious problem. And this theory does in fact have real-world support in the form of firmware issues [1].
However, it is also possible to trigger this using stress-ng on what the stress-ng man page terms "poorly designed hardware" [2]. And it is not necessarily a bad thing for the kernel to diagnose cases where heavy memory-contention workloads are being run on hardware that is not designed for this sort of use.
Nevertheless, it is quite possible that real-world use will result in some situation requiring that high-stress workloads run on hardware not designed to accommodate them, and also requiring that the kernel refrain from marking clocksources unstable.
Therefore, react to persistent long-latency reads by leaving the clocksource alone, but using the old 62.5-millisecond skew-detection threshold. In addition, the offending clocksource is marked for re-initialization, which both restarts that clocksource with a clean bill of health and avoids false-positive skew reports on later watchdog checks. Once marked for re-initialization, the clocksource is not subjected to further watchdog checking until a subsequent successful read from that clocksource that is free of excessive delays.
However, if clocksource.max_cswd_coarse_reads consecutive clocksource read attempts result in long latencies, a warning (splat) will be emitted. This kernel boot parameter defaults to 1000, and this warning can be disabled by setting it to zero or to a negative value.
[ paulmck: Apply feedback from Chao Gao and Oliver Sang. ]
Link: https://lore.kernel.org/lkml/20210513155515.GB23902@xsang-OptiPlex-9020/ # [1] Link: https://lore.kernel.org/lkml/20210521083322.GG25531@xsang-OptiPlex-9020/ # [2] Link: https://lore.kernel.org/lkml/20210521084405.GH25531@xsang-OptiPlex-9020/ Link: https://lore.kernel.org/lkml/20210511233403.GA2896757@paulmck-ThinkPad-P17-Gen-1/ Tested-by: Chao Gao [email protected] Tested-by: Jiri Wiesner [email protected] Signed-off-by: Paul E. McKenney [email protected]
Fixes up multiz atmos connection, cleans some things up in general (#63270)
About The Pull Request
ALLLRIGHT so Multiz atmos was letting gas flow down into things that should be well, not flowable into Like say doors, or windows.
This is weird.
Let's get into some context on why yeah?
First, how do things work currently?
atoms have a can_atmos_pass var defined on them. This points to a define that describes how they interact with flow. ATMOS_PASS_NO means well, if we're asked, block any attempts at flow. This is what walls use. ATMOS_PASS_YES means the inverse ATMOS_PASS_DENSITY means check our current density ATMOS_PASS_PROC means call can_atmos_pass, we need some more details about this attempt
These are effectively optimizations.
That var, can_atmos_pass is accessed by CANATMOSPASS() the macro It's used for 3 things.
1: Can this turf share at all? 2: Can this turf share with another turf 3: Does this atom block a share to another turf
All of this logic is bundled together to weed out the weak.
Anyway, so when we added multiz atmos, we effectively made a second version of this system, but for vertical checks.
Issue here, we don't actually need to. The only time we care if a check is vertical or not is if we're talking to another turf, it's not like you'll have an object that only wants to block vertical atmos. And even if you did, that's what ATMOS_PASS_PROC is for.
As it stands we need to either ignore any object behavior, or just duplicate can_atmos_pass but again. Silly.
So I've merged the two, and added an arg to mark if this is a verical attempt. This'll fix things that really should block up/down but don't, like windows and doors and such.
Past that, I've cleaned can_atmos_pass up a bit so it's easier for people to understand in future. Oh and I removed the second CANATMOSPASS from immediate_calculate_adjacent_turfs. It isn't a huge optimization, and it's just not functional.
It ties into zAirOut and zAirIn, both of which expect to be called with a valid direction. So if say, you open a door that's currently blocking space from leaking in from above, you end up with the door just not asking the space above if it wants to share, since the door can't zAirOut with itself.
Let's just wipe it out.
This makes the other code much cleaner too, heals the soul.
Anyway yadeyada old as ass bug, peace is restored to the kingdom, none noticed this somehow you'd think people would notice window plasma, etc etc. Why It's Good For The Game
MUH SIMULATION Also fuck window gas Changelog
cl fix: Fixed gas flowing into windows from above, I am.... so tired fix: Fixes gas sometimes not moving up from below after a structure change, see above /cl
RUN (later)
You know it isn't "Legos". You've had FUCKING YEARS to adjust to the actual, correct way to say the term. It's Lego. Lego bricks, Lego sets, Lego kits, Lego mini-figures, Lego City.
There are no such things as "Legos". They don't exist. "Lego" refers to the COMPANY THAT MAKES THE TOY, and thus the shortening Lego is acceptable. Saying "I'm playing with my Lego" works because it's referring to the sets themselves: The individuals aspects that make of the toy from the bricks to the mini-figures to the electronics to the other little parts. It isn't claiming that the fucking square bricks are each a Lego. THE ENTIRE THING IS. If you were to say "I'm playing with my Legos" that implies that you're playing with at least two different types of Lego set at once, i.e. Lego City and Bionicle.
Still saying LEGOS after all these years makes you look like an assclown. Here in Europe, the continent responsible for this toy (no, it wasn't made by America, no matter how much your capitalistic toy industry wants you to think), you'd be laughed out of the room if you said that.
cmdline: use colour error/warn labels
improves UX by helping to highlight problems in terminal output.
for now, as with the rest of the codebase, we rely upon only a
simple isatty() check for automatic colouring decisions, which
does not work for Windows. implementing isatty() for Windows to
could perhaps be tackled later.
note that user control over use of colour in terminal output via the
use of --color/--no-color options is deliberately ignored with
respect to the use of colour within error and warning output in
response to any problems encountered whilst processing the supplied
command-line arguments themselves (unknown option error; missing option
value error; obsolete option warning), having decided that this was the
best choice. this was questioned in review of this work, so i have
expanded/documented my thoughts on it here below.
-
default behaviour depends upon whether or not a detection routine determines that output is connected to a tty. if so then we choose to use colour in the hope that most users will appreciate the highlighting of problems. if not, i.e. output is thus being redirected into a log file or another application, we choose to not use colour because embeddeding terminal sequences into the output in such situations risks causing confusion due to the likely possibility of them not being consumed as intended.
the only situations where users may want or need to change this default behaviour, are when either:
a. they happen to dislike the use of colour. b. they want to force use of colour on Windows, due to current lack of a tty detection mechanism.
the latter of course becomes redundant as soon as we implement an
isatty()for Windows.it is reasonable in my opinion to fail to honour such a user preference for the limited circumstances of encountering a problem with the very data-set in which the user communicates that preference.
never-the-less, let's briefly explore the possible solutions that could in theory be implemented to try to honour such user preference for such output.
-
solution 1: "pre-scanning"
the concept was raised of "pre-scanning" the set of arguments to try to learn the user's indicated preference ahead of properly processing them, such that we can ensure that it is obeyed if/when outputting such an error/warning for a problem encountered in undertaking such processing. i.e. essentially walking through the argument list looking out for arguments matching a few fixed strings like "--color", and thus taking note of the preference before we begin the proper argument processing work.
it should be understood that the rules of proper argument processing dictate that you cannot with certainty know the nature of an argument until you have processed fully all of those preceeding it. options that take data values can be used with the value given within the same argument or supplied within the next one, and so you never know if an arbitrarily given argument must be consumed as a data value rather than treated as a possible option until you've processed all proceeding arguments; a special "early terminator" (
--) argument indicates that all subsequent arguments must be treated as generic arguments (that must not be interpretted as options); and an unknown option argument brings processing to a halt since it is not possible to correctly interpret the nature of anything subsequently given.despite this, practically speaking we could get away with pre-scanning - there are no "short" option forms of these toggle options to complicate things; and making simple assumptions that arguments matching "--color" or "--no-color" (or "--nocolor") are actual uses of those options is pretty reasonable along with assuming that a "--" argument is an actual early terminator, since such assumptions are almost always likely to be correct except in certain very unusual circumstances of broken CLI use or from users deliberately looking for flaws.
however, i do not feel that it is worth adding a chunk of code just to essentially ensure that a hypothetical and presumably rare CLI user who dislikes colour will not see it should they happen to make a mistake in their CLI usage.
(it might be noted that the vlc binaries do similarly flawed scans to steal one or two options, but that's not readily avoidable).
-
solution 2: "updating as we go":
as an alternative concept, we could, upon successfully processing each option, check if the option is
--coloror--no-colorand if so, update thecolorboolean accordingly, such that if we run into a problem and thus need to output an optionally coloured error or warning label, we might thus obey the user's preference when doing so.however, we have equal chance that we do the opposite since there could be a later argument that we did not yet get to that flips the preference the other way (e.g.
vlc --no-color --foo --color). in a worst case scenario the user might end up with a mix of coloured and non-coloured output that's messy and possibly confusing.again, i do not feel that it is worth implementing code to do this, to introduce an inefficiency into the option processing for such little benefit, especially with the risk of this creating a mess of inconsistency in some cases.
we (i) should endeavour to introduce isatty() support for Windows such
that Windows CLI users get the benefits of colour highlighting, but i
feel that it is perfectly reasonable to take a stance of not bothering to
try to enforce user no-color preference upon argument processing
errors/warnings.
FROMGIT: bpf: Do not change gso_size during bpf_skb_change_proto()
This is technically a backwards incompatible change in behaviour, but I'm going to argue that it is very unlikely to break things, and likely to fix far more then it breaks.
In no particular order, various reasons follow:
(a) I've long had a bug assigned to myself to debug a super rare kernel crash on Android Pixel phones which can (per stacktrace) be traced back to BPF clat IPv6 to IPv4 protocol conversion causing some sort of ugly failure much later on during transmit deep in the GSO engine, AFAICT precisely because of this change to gso_size, though I've never been able to manually reproduce it. I believe it may be related to the particular network offload support of attached USB ethernet dongle being used for tethering off of an IPv6-only cellular connection. The reason might be we end up with more segments than max permitted, or with a GSO packet with only one segment... (either way we break some assumption and hit a BUG_ON)
(b) There is no check that the gso_size is > 20 when reducing it by 20, so we might end up with a negative (or underflowing) gso_size or a gso_size of 0. This can't possibly be good. Indeed this is probably somehow exploitable (or at least can result in a kernel crash) by delivering crafted packets and perhaps triggering an infinite loop or a divide by zero... As a reminder: gso_size (MSS) is related to MTU, but not directly derived from it: gso_size/MSS may be significantly smaller then one would get by deriving from local MTU. And on some NICs (which do loose MTU checking on receive, it may even potentially be larger, for example my work pc with 1500 MTU can receive 1520 byte frames [and sometimes does due to bugs in a vendor plat46 implementation]). Indeed even just going from 21 to 1 is potentially problematic because it increases the number of segments by a factor of 21 (think DoS, or some other crash due to too many segments).
(c) It's always safe to not increase the gso_size, because it doesn't result in the max packet size increasing. So the skb_increase_gso_size() call was always unnecessary for correctness (and outright undesirable, see later). As such the only part which is potentially dangerous (ie. could cause backwards compatibility issues) is the removal of the skb_decrease_gso_size() call.
(d) If the packets are ultimately destined to the local device, then there is absolutely no benefit to playing around with gso_size. It only matters if the packets will egress the device. ie. we're either forwarding, or transmitting from the device.
(e) This logic only triggers for packets which are GSO. It does not trigger for skbs which are not GSO. It will not convert a non-GSO MTU sized packet into a GSO packet (and you don't even know what the MTU is, so you can't even fix it). As such your transmit path must already be able to handle an MTU 20 bytes larger then your receive path (for IPv4 to IPv6 translation) - and indeed 28 bytes larger due to IPv4 fragments. Thus removing the skb_decrease_gso_size() call doesn't actually increase the size of the packets your transmit side must be able to handle. ie. to handle non-GSO max-MTU packets, the IPv4/IPv6 device/ route MTUs must already be set correctly. Since for example with an IPv4 egress MTU of 1500, IPv4 to IPv6 translation will already build 1520 byte IPv6 frames, so you need a 1520 byte device MTU. This means if your IPv6 device's egress MTU is 1280, your IPv4 route must be 1260 (and actually 1252, because of the need to handle fragments). This is to handle normal non-GSO packets. Thus the reduction is simply not needed for GSO packets, because when they're correctly built, they will already be the right size.
(f) TSO/GSO should be able to exactly undo GRO: the number of packets (TCP segments) should not be modified, so that TCP's MSS counting works correctly (this matters for congestion control). If protocol conversion changes the gso_size, then the number of TCP segments may increase or decrease. Packet loss after protocol conversion can result in partial loss of MSS segments that the sender sent. How's the sending TCP stack going to react to receiving ACKs/SACKs in the middle of the segments it sent?
(g) skb_{decrease,increase}_gso_size() are already no-ops for GSO_BY_FRAGS case (besides triggering WARN_ON_ONCE). This means you already cannot guarantee that gso_size (and thus resulting packet MTU) is changed. ie. you must assume it won't be changed.
(h) changing gso_size is outright buggy for UDP GSO packets, where framing matters (I believe that's also the case for SCTP, but it's already excluded by [g]). So the only remaining case is TCP, which also doesn't want it (see [f]).
(i) see also the reasoning on the previous attempt at fixing this (commit fa7b83bf3b156c767f3e4a25bbf3817b08f3ff8e) which shows that the current behaviour causes TCP packet loss:
In the forwarding path GRO -> BPF 6 to 4 -> GSO for TCP traffic, the coalesced packet payload can be > MSS, but < MSS + 20.
bpf_skb_proto_6_to_4() will upgrade the MSS and it can be > the payload length. After then tcp_gso_segment checks for the payload length if it is <= MSS. The condition is causing the packet to be dropped.
tcp_gso_segment(): [...] mss = skb_shinfo(skb)->gso_size; if (unlikely(skb->len <= mss)) goto out; [...]
Thus changing the gso_size is simply a very bad idea. Increasing is unnecessary and buggy, and decreasing can go negative.
Fixes: 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper") Signed-off-by: Maciej Żenczykowski [email protected] Signed-off-by: Daniel Borkmann [email protected] Cc: Dongseok Yi [email protected] Cc: Willem de Bruijn [email protected] Link: https://lore.kernel.org/bpf/CANP3RGfjLikQ6dg=YpBU0OeHvyv7JOki7CyOUS9modaXAi-9vQ@mail.gmail.com Link: https://lore.kernel.org/bpf/[email protected]
(cherry picked from commit 364745fbe981a4370f50274475da4675661104df https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=364745fbe981a4370f50274475da4675661104df ) Test: builds, TreeHugger Bug: 188690383 Signed-off-by: Maciej Żenczykowski [email protected] Change-Id: I0ef3174cbd3caaa42d5779334a9c0bfdc9ab81f5
2021-12-18
Saturday, December 18th, 2021 - the week early Christmas show! Look, it's been a couple of years right? Life's hard, and normal feels like a distant memory even though we're still grasping for it at every opportunity. 18 months ago I did a Christmas in July show in part because it was funny, but also because Christmas is a seasonal comfort blanket, and even though sometimes it can take a minute to suppress your inner Grinch, it is (I hope) a time of year that brings with it fond memories as far back as you can remember. It's taken a while to feel Christmassy this year, but with the aid of the perfect hangover, and a large Covid coffee, we got there pretty quickly. Merry Christmas and Happy Holidays to everyone, whatever that means to you and however you choose to celebrate! Resist the eye roll, suppress the pessimism, let today's show be a time machine to your best Christmases, and a toast to those in the future!
Update README.md
You Get 100% Premium High-Quality Work, Fast time delivery, Clean And modern work. If you want to communicate for your projects you can connect me with zoom, meet, video calling, voice calls, etc. My main focus is client satisfaction. I have 3 years plus experience in this sector, After completing the project then Any time you feel any problem with your projects you get support 24/7 Always Don't Worry! Support is totally free I will change my experience with work you. So, what do you think? I'm ready for you and your business, I will best try to grow your business with my work It's my full confidence. So let's go start. If you have any questions inbox me and let's start the project quickly why late.
Thanks Developer Emon
Resolve user visibility in UserLoader
There has been a long-standing performance issue with the is_private method of the User model, because it attempts to count the number of published posts for each user, a potentially very expensive operation. And since the operation is uncached, this can very quickly overwhelm the database.
More discussion of the issue: wp-graphql/wp-graphql#961
At Quartz, this has prevented us from upgrading WPGraphQL, and it appears to have affected other users as well. A few different PRs exist to address this issue:
wp-graphql/wp-graphql#962 wp-graphql/wp-graphql#972 wp-graphql/wp-graphql#1677
This PR is my attempt to fix this issue the way that Jason and others have described as ideal: using DataLoader.
Instead of creating a new loader (e.g., "UserVisibilityLoader"), I am including this in UserLoader. The reason is that they seem tightly coupled and making them separate would just introduce unnecessary complexity. You'd need to remember to use UserVisibilityLoader everywhere you used UserLoader or risk losing the performance benefit it provides.
My fix simply plugs into the existing "loadKeys" implementation and
produces a single query that determines visibility for each user. I'd
love feedback on the efficiency of this query; I hope that this is
good enough to sidestep the need for caching. If its not possible to
generate a single efficient query, generating an extra query for each
user along the lines of SELECT id FROM wp_posts WHERE post_author = X LIMIT 1 seems like the next best approach.
Finally, we need a way to provide the visibility to the User model. Luckily, WP_User is not a final class and provides a setter:
https://developer.wordpress.org/reference/classes/wp_user/__set/
This allows us to set an "is_private" property on the WP_User instance, which is then available to the model via "$this->data". This seems to be done widely, but we could implement a wrapper around WP_User if we wanted to avoid mutating WP_User instances.
From there, it's a very simple matter of having the User model check this property.
PIP SHIT
Shut the fuck up you stupid fucking bitch. Did you really think I was going to play along with your old annoying ass unfunny joke. God you fucking degenerate filth. You disgust me in every way possible and I will hang you for your crimes.
"10:55am. I've went to bed on time yesterday just as I should have. It is just that I spent some time lounging in bed.
cb_flossin: ///
Also, I think for the future of AI research, we need hardware and languages designed with sparsity in mind- so that could be a good direction.
///
abstractcontrol: ///
Sparsity is a consequence of conditional computation, the equivalent of if statements in a handcrafted program. I've watch some of the vids by companies like TensTorrent and Groq, and they are going in that direction. Partly because matrix multiplication is an O( n^3 ) operation and the only way to improve on that is to make it sparse.
I've been thinking about my failures to break through both this year and back in 2018. Maybe we are all doing ML research the wrong way by relying on our own intellect. No human can understand anything of higher dimensional geometry.
Maybe once the hardware is good enough, it itself will give us an answer as to have to best use it. By that I mean that we should just use genetic programming to evolve the appropriate learning algos. On CPUs+GPUs I would not even imagine trying that because they'd be too slow, but on future hardware that should be viable.
Right now, it is just extremely difficult to make any progress, but if I had an oracle that could, conditioned on realistic hardware constraints, give me optimal learning algorithms for a game of my choosing, I'd expect it would be extremely enlightening.
This also gives an answer to the question that given that we can't make progress beyond backprop, just why do we think we will be able to go to superhuman once we get to the human level. It is a waste of time expecting some genius to enlighten us as to what the next step should be. Right now the ML community is busy producing an even increasing quantity of garbage papers and labeling it progress. I won't find what I want in any of them.
///
Did some Reddit posting.
Here is the link.
11:15am. Let me chill for a bit and then I will start. I really need to make the Groq and Graphcore posts. After that I'll look into SambaNova. I think it is some old school kind of company. It did not really impress me when I researched it like TensTorrent did. I'll check out if it has anything new on Youtube.
12:40pm. Done with chores. Let me have breakfast.
1:15pm. Let me start otherwise I will never get going. More shader tuts coming right up.
https://youtu.be/cQ0qtcSymDI All 80+ Blender material nodes explained in under 30 minutes
Let me watch this.
https://youtu.be/cQ0qtcSymDI?t=153
This is quite cool.
I need to focus on this video.
Ok, first of all, what is ambient occlusion?
https://youtu.be/lB7l_IUcQn4 Blender 2.8 Eevee Tutorial - How to Use Ambient Occlusion (AO) to Make Your Renders POP!
I am not sure I get it despite watching this, but I got the gist of it.
1:40pm. https://youtu.be/cQ0qtcSymDI?t=395
This video is is pretty useless. Let me move to something else.
1:45pm. https://youtu.be/n1qv0gowPwk?t=12 Blender - Stylized Glass Shader in Blender 2.8
Let me take a look at this. I watched the glass tutorial video again. I'll watch a bunch more things today and then I am going to leap into doing my own stuff. There aren't many vids on Blender shaders out there.
Focus me. Stop thinking about the third run. Master Blender shading.
https://www.youtube.com/channel/UCuNhGhbemBkdflZ1FGJ0lUQ
This is Ducky 3D's channel. At this point in my development I starting to reach a phase where just putting things into Youtube is not enough to give me what I want. EVentually I'll have to dive into these educator's vids directly.
https://youtu.be/aY-Bqfshfv8 Procedural Lava Rock Material (Blender Tutorial)
Let me take a look at this.
https://youtu.be/aY-Bqfshfv8?t=116
Huh, I am surprised you can get light to work like that. Impressive.
https://youtu.be/aY-Bqfshfv8?t=195
Despite it being a relatively recent vid, he is still using experimental features. Ok.
https://youtu.be/aY-Bqfshfv8?t=302
It says that 'object' places the texture around the object more evenly.
https://youtu.be/aY-Bqfshfv8?t=359
This guy is so thorough in explaining what he is doing. What a champ.
https://youtu.be/aY-Bqfshfv8?t=426
This is really nice.
https://youtu.be/aY-Bqfshfv8?t=703
This is pretty cool. If some day I managed to merge this together with my programming, I'll really have everything.
2:30pm. https://www.youtube.com/results?search_query=blender+displacement
It might be worth looking into displacement. It worked for me on a plane, but not so much on that rock.
2:50pm. Had to take a break. Let me resume. What is the next vid?
https://youtu.be/ATiU1T06EmQ Geometry Nodes as Creative Outlet | Blender 3.0 tutorial
Let me watch this.
https://youtu.be/ATiU1T06EmQ?t=624
Yeah, this is cool.
3:10pm. Done with that vid.
https://www.youtube.com/watch?v=2Wlc5PXo6pE 3 Different Quick Effective TEXTURING TECHNIQUES - Hunting Knife - Blender 2.8
https://www.youtube.com/watch?v=5UCc3Z_-ibs How to Make Studio Lighting in Blender
https://www.youtube.com/watch?v=iVjnS5Z77Ww Advanced Materials in Blender 2.80 | Shader Editor Tutorial
Let me take a look at these 3 from top to bottom.
https://youtu.be/2Wlc5PXo6pE?t=233
Project from view gives good results.
https://youtu.be/2Wlc5PXo6pE?t=755
This is the first time I see texture painting done in action. It is not bad.
https://youtu.be/2Wlc5PXo6pE?t=820
He says he can't remember where he found this texture, but this is the same thing I used in the CG fast track course.
https://youtu.be/2Wlc5PXo6pE?t=1046
Ahhhhh, you can flip it like this! I've been wondering about this ever since I found out about the color ramp.
3:45pm. Let me take off just for a bit...
https://youtu.be/5UCc3Z_-ibs?t=482
He using something called viewport denoising here. I'd want to try that out. Also why is his cycles rendering so fast? Is it because of that?
It only works with RTX cards. Agh...nevermind.
3:55pm. Let me step away again. I am installing GPU drivers for my bro at the moment. It should have finished downloading.
4:15pm. I've looked up a cheap HDD for him. Ok, let me get back to watching the vids. Today is full of distractions for me. I haven't even gotten to making those Reddit posts.
4:25pm. He says he has 2 RTX Titans. No wonder it is so fast for him.
4:30pm. Let me watch the last one. After that I'll look at a displacement tutorial.
https://youtu.be/iVjnS5Z77Ww?t=94
I should keep this resource in mind.
5pm. https://www.youtube.com/watch?v=xF-l5d80oCU How to Use Displacement Maps in Blender (Tutorial)
I am at my limit here with the tutorials. Let me take a break and then I will watch this. After that I think I am done. I am going to get to work on my own stuff. I've learned shading and geometry nodes. Actually, no, I need to cover texture painting as well.
After that I'll be done.
5:30pm. Let me watch it.
https://youtu.be/xF-l5d80oCU?t=475
Ah, I can use the simple to avoid the plane turning into a circle.
5:45pm. Okay. It really is hard to just keep watching tutorials. It has only be a few hours, but I already had enough. Still, I need to do a bit more.
https://www.youtube.com/watch?v=4XYhrKEycaU Texture Paint your Sculpts without Retopology (Blender Tutorial)
I need to watch this.
Also I need to learn how to do my own HDRIs. I need that abyssal space background.
https://youtu.be/4XYhrKEycaU?t=431
He really should have gone over it with a slide relax tool.
I just checked my own mesh, and it does seem like there are a lot of overlaps.
https://youtu.be/4d4N8d4ki2Y Texture Painting in Blender for Beginners (Tutorial)
This is 1h. I'll leave it for later.
https://www.youtube.com/results?search_query=blender+hdri
How do I make these things. Probably HDRIs are not specific to blender.
https://www.youtube.com/watch?v=etOkgjrTfa8 How to create an HDRI map
Let me watch this.
https://youtu.be/etOkgjrTfa8?t=314
Sigh, can't I just paint inside the sphere, and then export that into CSP for coloring?
6:40pm. Done with lunch. Let me finish the HDRI vid.
No, this is not what I am looking for. Though it is interesting to found out how HDRIs are created, what I need is a tutorial on how to draw and paint them.
https://www.youtube.com/watch?v=HPAuBvbsWXo Make Your Own HDRI for Free in Blender 2.82
This is only 3m and seems promising.
https://youtu.be/HPAuBvbsWXo?t=127
Oh this is interesting. It turns out it is really easy to make a HDRI in Blender itself. This might be worth considering.
https://youtu.be/XZmr-XYRw3w How to create a hand-painted skybox for Unity using Photoshop | Mini-tutorial
https://youtu.be/XZmr-XYRw3w?t=158
Photoshop sure is amazing. I wonder if I will be able to do this in CSP? My guess is on the side of no. I'll have to make sure.
https://youtu.be/6u7MYVmkwyE Render Your Own 360 HDRI in Blender!
Let me watch this as well. It is only 3m. Just as well, because I am at my aboslute limit.
https://youtu.be/RsAUfQlZH_w HDRIs Just Got Better
This is really interesting. Let me watch this as well.
https://www.youtube.com/watch?v=YLzo7SgGMwI 360 Spherical Image Animated Background in Clip Studio
Also I found this. I should look up spherical paintings.
7:15pm. https://www.youtube.com/watch?v=_gXlUm_qGdM Backgrounds with 3D in Clip Studio Paint
No, not this last one. But it is a subject I will be interested in once it is time to go from 3d to 2d.
...I am thinking.
I thought that I would paint the space in CSP or something, but now I am thinking of doing it in Blender since it has such good functionality ofr creating HDRIs.
Though for that to work I am going to have to do more research. Stars, cosmic fog, non rigid objects that transition between solid and gas. The scene itself is not that complicated, but I do not know how to make it in Blender.
Stars for example could be done by propagating light through a fog. I think I did something like that in CG fast track's course, but I forgot how that went by now. Sheesh.
This is just more time I need to spend before I can start, but challenges like this are what makes things fun. I should also learn how to do water.
7:30pm. It will take a while before I can do things with efficiency. I need to go through this gauntlet.
I still have a bit left before I can do things on my own.
I keep delaying those Reddit posts as well, but right now I just do not feel like thinking about it. I want to get the tutorials out of the way, after that I'll have some freedom of movement. Right now let me have some fun."
lib/sort: make swap functions more generic
Patch series "lib/sort & lib/list_sort: faster and smaller", v2.
Because CONFIG_RETPOLINE has made indirect calls much more expensive, I thought I'd try to reduce the number made by the library sort functions.
The first three patches apply to lib/sort.c.
Patch #1 is a simple optimization. The built-in swap has special cases for aligned 4- and 8-byte objects. But those are almost never used; most calls to sort() work on larger structures, which fall back to the byte-at-a-time loop. This generalizes them to aligned multiples of 4 and 8 bytes. (If nothing else, it saves an awful lot of energy by not thrashing the store buffers as much.)
Patch #2 grabs a juicy piece of low-hanging fruit. I agree that nice simple solid heapsort is preferable to more complex algorithms (sorry, Andrey), but it's possible to implement heapsort with far fewer comparisons (50% asymptotically, 25-40% reduction for realistic sizes) than the way it's been done up to now. And with some care, the code ends up smaller, as well. This is the "big win" patch.
Patch #3 adds the same sort of indirect call bypass that has been added to the net code of late. The great majority of the callers use the builtin swap functions, so replace the indirect call to sort_func with a (highly preditable) series of if() statements. Rather surprisingly, this decreased code size, as the swap functions were inlined and their prologue & epilogue code eliminated.
lib/list_sort.c is a bit trickier, as merge sort is already close to optimal, and we don't want to introduce triumphs of theory over practicality like the Ford-Johnson merge-insertion sort.
Patch #4, without changing the algorithm, chops 32% off the code size and removes the part[MAX_LIST_LENGTH+1] pointer array (and the corresponding upper limit on efficiently sortable input size).
Patch #5 improves the algorithm. The previous code is already optimal for power-of-two (or slightly smaller) size inputs, but when the input size is just over a power of 2, there's a very unbalanced final merge.
There are, in the literature, several algorithms which solve this, but they all depend on the "breadth-first" merge order which was replaced by commit 835cc0c8477f with a more cache-friendly "depth-first" order. Some hard thinking came up with a depth-first algorithm which defers merges as little as possible while avoiding bad merges. This saves 0.2*n compares, averaged over all sizes.
The code size increase is minimal (64 bytes on x86-64, reducing the net savings to 26%), but the comments expanded significantly to document the clever algorithm.
TESTING NOTES: I have some ugly user-space benchmarking code which I used for testing before moving this code into the kernel. Shout if you want a copy.
I'm running this code right now, with CONFIG_TEST_SORT and CONFIG_TEST_LIST_SORT, but I confess I haven't rebooted since the last round of minor edits to quell checkpatch. I figure there will be at least one round of comments and final testing.
This patch (of 5):
Rather than having special-case swap functions for 4- and 8-byte objects, special-case aligned multiples of 4 or 8 bytes. This speeds up most users of sort() by avoiding fallback to the byte copy loop.
Despite what ca96ab859ab4 ("lib/sort: Add 64 bit swap function") claims, very few users of sort() sort pointers (or pointer-sized objects); most sort structures containing at least two words. (E.g. drivers/acpi/fan.c:acpi_fan_get_fps() sorts an array of 40-byte struct acpi_fan_fps.)
The functions also got renamed to reflect the fact that they support multiple words. In the great tradition of bikeshedding, the names were by far the most contentious issue during review of this patch series.
x86-64 code size 872 -> 886 bytes (+14)
With feedback from Andy Shevchenko, Rasmus Villemoes and Geert Uytterhoeven.
Link: http://lkml.kernel.org/r/f24f932df3a7fa1973c1084154f1cea596bcf341.1552704200.git.lkml@sdf.org Signed-off-by: George Spelvin [email protected] Acked-by: Andrey Abramov [email protected] Acked-by: Rasmus Villemoes [email protected] Reviewed-by: Andy Shevchenko [email protected] Cc: Rasmus Villemoes [email protected] Cc: Geert Uytterhoeven [email protected] Cc: Daniel Wagner [email protected] Cc: Don Mullis [email protected] Cc: Dave Chinner [email protected] Signed-off-by: Andrew Morton [email protected] Signed-off-by: Linus Torvalds [email protected] Signed-off-by: Yousef Algadri [email protected] Signed-off-by: Panchajanya1999 [email protected] Signed-off-by: Forenche [email protected]
oh my god i am stupid. What a stupid mistake jesus.
Do not allow focus to drift from fullscreen client via focusstack()
It generally doesn't make much sense to allow focusstack() to navigate away from the selected fullscreen client, as you can't even see which client you're selecting behind it.
I have had this up for a while on the wiki as a separate patch[0], but it seems reasonable to avoid this behaviour in dwm mainline, since I'm struggling to think of any reason to navigate away from a fullscreen client other than a mistake.
0: https://dwm.suckless.org/patches/alwaysfullscreen/
attempt making 2012 player work and giving up afterwards because fuck you