|
feedmegin posted:I am well aware of that thank you. The ARM7TDMI came out in 1994. Decades ago as I said. I would suggest the guy talking about 8 byte ARM instructions is perhaps just a little out of their depth here. Peace. I only pointed it out because it's important to the point I was trying to make and got the specifics wrong. Not as some kind of conversational judo where in fact I was not wrong.
|
#
?
Oct 30, 2021 23:19
|
|
|
|
| # ? Jun 2, 2024 14:51 |
|
|
Come to think of it the real reason early RISC wouldn't do it is it breaks the classic RISC pipeline https://en.m.wikipedia.org/wiki/Classic_RISC_pipeline in half. You want one clock cycle for both those first two parts exactly. You could do that with something Thumb like i think given the spare transistors (which as I noted they didn't have to start with) but x86 style? Nah.
feedmegin fucked around with this message at 00:19 on Oct 31, 2021 |
|
#
?
Oct 30, 2021 23:30
|
|
|
pseudorandom name posted:you just listed a bunch of business reasons why developers don't waste money on technical effort no, I was trying to explain that pretty much like other aspect of game development loading times are part of a balancing effort that is only indirectly informed by business requirements and much more directly by what the game design team wants to achieve (which is mostly to make a good game) but well *points at seagull* business by the way we do "waste money on technical effort", things don't just happen
|
|
#
?
Oct 30, 2021 23:43
|
|
|
BlankSystemDaemon posted:As for ARM, I think the instruction to optimise javascript means it might not be a RISC architecture anymore, no matter what it says on the tin. reminder that the original contrast was with CISC, Complex Instruction Set Computer. the alternate (and more accurate imo) expansion of RISC is Reduced Instruction Set Complexity complex is a dimension of instruction set architecture only loosely coupled to the number of different instruction opcodes. it's more about ease of implementation. does your ISA do things which are difficult to implement? then maybe it's a CISC in this specific case, FJCVTZS is quite easy to implement, and highly similar to another arm64 instruction, FCVTZS. they're both FP to int conversions with rounding towards zero. the "js" version adds a small but impactful (to js engines) extra feature, detection of whether the conversion was exact you see, the JS virtual machine supports a single way to represent most numbers, IEEE 754 double precision floating point. however, JS also tries to support operations that treat floats as if they're ints - think AND/OR/XOR/etc. the "brilliant" conceit here is that so long as your integer is small enough, the double precision mantissa can represent it exact, so why bother having more than one type of number? but cpus don't have FPU ops like "AND the mantissa of two double precision floats together, producing a double". every time a JS program wants to do this kind of poo poo, JS engines convert from FP to int, check if the result is exact, do error handling if it's not ("wtf javascript coder, you tried to use a NaN as if it was a legal int"), perform the bitwise operation in integer registers, then convert back to FP since the check for exact conversion is surprisingly costly to implement in software, but trivial in hardware, and since it's natural for any instruction which writes to the integer register file to also set flags for subsequent branches to act on, FJCVTZS is an on-theme RISC answer to the problem (that said, it would be off-theme if JS performance wasn't all that important - but regrettably, it is)
|
|
#
?
Oct 31, 2021 01:50
|
|
|
is it ethical to work towards making JavaScript faster given all the problems it’s caused, is continuing to cause, and will cause? terrible numerics is yet another reason Netscape should’ve just used Scheme instead of letting Eich throw together his own language
|
|
#
?
Oct 31, 2021 02:43
|
|
|
to offer a slight correction, formally all numbers in js are double-precision floating point, but for efficiency most js engines have a redundant representation for numbers that they know fit into some range of small integers, usually at least the 32-bit signed range so e.g. if you’re adding two values that happen to be small integers, you just do the integer addition and then test for overflow. if it doesn’t overflow, you can wrap your small integer back up as a js value. if it overflows, you have to represent the result as a double none of that so far needs the conversion. but sometimes for whatever reason you start with an opaque double, like maybe you multiplied two values and one of them was a double. if you need to wrap that up as a js value, you probably want to use the small-integer representation if you can, so that downstream code can immediately see it’s an integer and fall into the integer fast paths. if you don’t do this, you can easily get stuck taking all the double paths downstream and lose a lot of performance so that’s where the conversion comes in: you want to get the integer value but also know immediately if you lost information that means you need to stick with double. like if the operand was negative zero. otherwise, you basically have to do the conversion, do the reverse conversion, and then test for bitwise equality, all of which is a lot more expensive
|
|
#
?
Oct 31, 2021 03:04
|
|
|
rjmccall posted:but sometimes for whatever reason you start with an opaque double, like maybe you multiplied two values and one of them was a double. if you need to wrap that up as a js value, you probably want to use the small-integer representation if you can, so that downstream code can immediately see it’s an integer and fall into the integer fast paths. if you don’t do this, you can easily get stuck taking all the double paths downstream and lose a lot of performance that makes a lot more sense tbh same general reason for the instruction to exist, but i didn't have quite the right concept of what's going on in a js JIT
|
|
#
?
Oct 31, 2021 03:34
|
|
|
cum jabbar posted:just wait 5 minutes after x startup for it to stop consuming all of your disk io that's five minutes I could be spending shitpoating no
|
|
#
?
Oct 31, 2021 08:58
|
|
|
pseudorandom name posted:Non-technical video game nerds keep going on and on about how SSDs are going to change everything and how consoles can now replace the entire contents of RAM from the SSD faster than you can spin the camera around the scene and how DirectStorage will be revolutionary on Windows 11 and I keep attempting to explain to them that load times are a business decision, not a technical one, and while Naughty Dog might be willing to devote multiple man years to making the loads instant and invisible, the only thing that SSDs will do for most games is allow the developer to spend even less time optimizing their level design and engine performance and whatnot. speaking of load times and this being the linux thread, i cut my load times by like 90% in most games i play by switching to linux. i always thought paradox games just have to sit on the initial load screen for a minute, and then again hang for half a minute on loading a late-game save state, but nope, ~5 second load times on both the native version and through proton, on same hardware OTOH, there's guild wars 2, which just takes forfuckingever to load maps with lots of players regardless of OS. then again they're using dx9 in tyool 2021 so who the gently caress knows what's going on there but yeah other than a few weird outliers that apparently just run bad everywhere, windows just seems really bad for video games lmao
|
|
#
?
Oct 31, 2021 13:16
|
|
|
Truga posted:windows just seems really bad for video games lmao lol. lmao.
|
|
#
?
Oct 31, 2021 15:15
|
|
|
I like systemd but there is a significant performance penalty for going full-on everything is a dbus microservice in an embedded system; IIRC the raw socket endpoints at work are ~20 times faster in terms of RTT/processing time when you're doing many thousands or requests per second it adds up, a lot e: before someone goes have you measured, the difference is 200ms vs. 4s in processing time for some user interactions and this maps perfectly to the processing time for individual requests Private Speech fucked around with this message at 16:27 on Oct 31, 2021 |
|
#
?
Oct 31, 2021 16:21
|
|
|
Captain Foo posted:lol. lmao. i mean, i'm mostly joking but also this PoE league saw a bunch of crashes for people on windows and zero for me lol
|
|
#
?
Oct 31, 2021 17:02
|
|
|
The thing is, systemd isn't -one- thing. systemd-init is good, and is miles above every other init system on Linux. It's just better, especially for it's sandboxing capabilities. Systemd-journald is a good system with a few missing features. Journalctl is a terrible CLI tool. It's almost as lovely as the git CLI. systemd-networkd is good on embedded systems, or other applications with a well-defined configuration. It's bad on desktops/laptops. systemd-resolved can eat a bag of dicks. systemd-homed is a bunch of bullshit that nobody wants. systemd-nspawn replaces stuff that was fine before, and does it for *~ReAsOnZ*~. The systemd project is a badly governed monolithic codebase that ignores the will of the community. IBM also owns it now. Systemd only works on Linux, and the systemd project is sprouting dependencies in a ton of Redhat-maintained software like GNOME. That effectively cuts the BSD family off from a lot of software that used to work fine. Everybody points to the bad parts and says "systemd bad" or the good parts and says "systemd good" while ignoring that's it's actually both at the same time. Poopernickel fucked around with this message at 17:16 on Oct 31, 2021 |
|
#
?
Oct 31, 2021 17:05
|
|
|
Truga posted:OTOH, there's guild wars 2, which just takes forfuckingever to load maps with lots of players regardless of OS. then again they're using dx9 in tyool 2021 so who the gently caress knows what's going on there good(ish?) news; it sounds like they were stuck to dx9 due to a bunch of legacy stuff from the launch about a decade ago, so they've been modernizing and they have a dx11 beta option in the video setting panel that helps bundle calls more effectively not sure how that'll translate to linux with a wrapper, but it seems to have cut down a lot of the cpu churn for me and helped fps a bit on the low end. it still had some quirks, but initial performance seems good and there's less hitching there's also a fan-made d9d12pxy project that does similar and helps with lower fps, though the initial cache generation means it'll be slow for the first few major areas. the creator has also tailored it for some other dx9 mmos and games with user assistance so it could be useful for other clunkers
|
|
#
?
Oct 31, 2021 17:07
|
|
|
Poopernickel posted:Everybody points to the bad parts and says "systemd bad" or the good parts and says "systems good" while ignoring that's it's actually both at the same time.
|
|
#
?
Oct 31, 2021 17:12
|
|
|
Shell-script based init systems can gently caress right off though, especially if you have complex service dependencies or need any sandboxing. Use busybox-init if you're doing a little initramfs or something. Use systemd as soon as you care about service reliability or have any service dependencies. Poopernickel fucked around with this message at 17:35 on Oct 31, 2021 |
|
#
?
Oct 31, 2021 17:22
|
|
|
Truga posted:speaking of load times and this being the linux thread, i cut my load times by like 90% in most games i play by switching to linux. i always thought paradox games just have to sit on the initial load screen for a minute, and then again hang for half a minute on loading a late-game save state, but nope, ~5 second load times on both the native version and through proton, on same hardware Windows has a notoriously terrible IO stack, which makes (among other things) doing IO on lots of tiny files perform atrociously. Most games package their assets up into a few multi-gigabyte files, but Paradox doesn't spend any effort on their load times because they don't have any competition for the kinds of games they make.
|
|
#
?
Oct 31, 2021 17:28
|
|
|
Poopernickel posted:The thing is, systemd isn't -one- thing. It's way more than that list now. Many of the LSB Daemons have systemd alternatives. That's essentially what systemd has become, a LSB init/daemon replacement. Poopernickel posted:The systemd project is a badly governed monolithic codebase that ignores the will of the community. IBM also owns it now. They've accepted tons of patches to add optional configurations. The versions of systemd that the major distributions ship are so different they link to the different bug trackers. The major options/features debian has asked to be included in upstream have been. I agree they don't care what other people think the default configuration should be. The only totally unreasonable action I'm aware of was refusing to change behavior for debug on the kernel command line. Linus took care of it. The real issue has been the distributions that didn't care how badly they broke things for their users. Debian had a vote, delayed by a release, and most technical considerations were put forward about the change. Debian has a means still to install sysv init and the LSB, but it's up to the people who want it to maintain it. Including writing config packages for packages maintained by people who don't want to support it. Most of the complaints about systemd are (currently) a non-issue on Debian. You can drop to single user mode and replace systemd. If you want sysv init and the legacy daemons to stay revelant, you need to step up to maintain them. The people currently doing the bitch work to make sure Debian runs on your computer now vastly prefer systemd because they were the ones dealing with the headaches. Poopernickel posted:Systemd only works on Linux, and the systemd project is sprouting dependencies in a ton of Redhat-maintained software like GNOME. That effectively cuts the BSD family off from a lot of software that used to work fine. I disagree that GNOME is maintained or owned by redhat. It has a foundation that helps steer development, and AFAIK the BSDs have not been members the past ten years. They may have never been members. FreeBSD doesn't have the userbase to maintain their ports collection. That's not the fault of either GNOME or systemd. SYSV Fanfic fucked around with this message at 01:27 on Nov 1, 2021 |
|
#
?
Nov 1, 2021 01:18
|
|
|
Truga posted:i mean, i'm mostly joking but also this PoE league saw a bunch of crashes for people on windows and zero for me lol i too play poe and it is notorious for being bizarre with stability between patches so i wouldn't really call this a linux thing
|
|
#
?
Nov 1, 2021 01:26
|
|
|
please go post about BSD in the BSD thread
|
|
#
?
Nov 1, 2021 01:31
|
|
|
The difference in load times for poorly packaged unity games is nuts. I think pathfinder kingmaker and pillars of eternity 2 both transitioned areas in half the time under proton.
|
|
#
?
Nov 1, 2021 01:31
|
|
|
Private Speech posted:I like systemd but there is a significant performance penalty for going full-on everything is a dbus microservice in an embedded system; IIRC the raw socket endpoints at work are ~20 times faster in terms of RTT/processing time do i spy another member of the armv5 in 2021 crew? 
|
|
#
?
Nov 1, 2021 01:41
|
|
|
What kind of embedded stuff do you guys work on?
|
|
#
?
Nov 1, 2021 02:04
|
|
|
Private Speech posted:I like systemd but there is a significant performance penalty for going full-on everything is a dbus microservice in an embedded system; IIRC the raw socket endpoints at work are ~20 times faster in terms of RTT/processing time Is this with classic dbus or the new dbus-broker? dbus itself is fairly slow which is why various people have tried to add linux kernel ipc primitives similar to dbus over the years, all of which got rejected because they bear the stench of that perfidious Poettering!! ... well, amongst other reasons. dbus has other problems though, like the lack of nullability and a rather synchronous programming model. wayland and x11 allow clients to asynchronously create objects on the server and tell the server what object ID the new object should use, then queue up a bunch of messages addressed to that not-yet-extant object using that designated object ID. dbus has a system of object path strings instead, so this asynchronous creation behavior isn't a first-class feature of the protocol.
|
|
#
?
Nov 1, 2021 02:23
|
|
|
pseudorandom name posted:Non-technical video game nerds keep going on and on about how SSDs are going to change everything and how consoles can now replace the entire contents of RAM from the SSD faster than you can spin the camera around the scene and how DirectStorage will be revolutionary on Windows 11 and I keep attempting to explain to them that load times are a business decision, not a technical one, and while Naughty Dog might be willing to devote multiple man years to making the loads instant and invisible, the only thing that SSDs will do for most games is allow the developer to spend even less time optimizing their level design and engine performance and whatnot. Lmbo if you think SSDs aren't a game changer, RDR2 goes from a 5 minute load to 30 seconds. Also have you looked at a game from 5-10 years ago vs. anything modern? Y'all are massively understating the technological differences. Textures have gotten huge, which will load significantly faster from an ssd.
|
|
#
?
Nov 1, 2021 02:44
|
|
|
i remember being amazed how fast apt-get upgrade was after switching from a 5400rpm to an ssd
|
|
#
?
Nov 1, 2021 03:33
|
|
|
Yeah, you're one of those people who has conceptual difficulty with business decisions. There is a load time threshold that humans are willing to tolerate. If your load times are above this threshold, your game will lose sales. It is worth spending your development money to reduce load times below that threshold. (Although you're not going to want to spend more money than you'll lose from the lost sales due to bad load times.) Previously this threshold was set by the speed of CD-ROM drives and then DVD drives and then hard disks, and thus games were optimized to satisfy the threshold when running off of their target platform's storage media. When you move a game optimized for hard disks to a SSD, naturally it will run faster, because it was designed to run off a slower disk. Now that SSDs have become standard, games will be optimized to meet the threshold when running off of SSDs. This is because the allocation of development resources is a business decision, and businesses don't actually care about load times, businesses care about doing the bare minimum necessary to avoid losing sales. Ubiquitous SSDs will allow businesses to take the people who normally spent the entire project fighting a losing battle against load times and instead devote them to fighting the same losing battle against framerates or tightening up the graphics on level 3 or whatever.
|
|
#
?
Nov 1, 2021 03:41
|
|
|
animist posted:i remember being amazed how fast apt-get upgrade was after switching from a 5400rpm to an ssd Same. only other moment like it was downloading IE5 on ADSL for the first time. Fastest connection I'd ever used was ISDN.
|
|
#
?
Nov 1, 2021 05:38
|
|
|
Right, and distribution size is also a business issue. Windows 95 used to ship on thirteen floppy disks, so clearly consumers were willing to swap through thirteen disks in order to install their OS. (OS/2 Warp used 25 floppies.) Therefore, once CD drives and later DVD drives became common, Microsoft happily deleted all packaging processes from its development pipeline and shipped Windows as thirteen CDs, and later thirteen DVDs. Wait, no they didn't, because that kind of business feedback loop isn't anywhere as elastic or precise or immediate as you're making it sound and it's in fact one tiny logic jump short of "if you add seatbelts to cars, people will just drive more recklessly".
|
|
#
?
Nov 1, 2021 05:47
|
|
|
pseudorandom name posted:Yeah, you're one of those people who has conceptual difficulty with business decisions. What are you even talking about. Literally nobody is arguing that business will do the bare minimum, of course they will. That doesn't change the fact there is a huge and material change going from an HDD to an SSD, which is what every game console has done this / last generation, and it is in fact "a game changer". It doesn't matter if the company spends zero effort optimizing loading its still going to load 10x faster at a minimum and by your own argument it doesn't matter if they're developing for a HDD why would they give a poo poo either way. GTA Online is famously and simultaneously the worst loading and the best selling game of all time, and they couldn't be assed to spend the afternoon with a profiler to fix one of the most notoriously simple bugs causing 10 minute load screens for nearly a decade. What "load optimization threshold" where they spending man hours on, exactly?
|
|
#
?
Nov 1, 2021 06:14
|
|
|
5.15 is out! proper in-kernel ntfs driver, and ksmbd
|
|
#
?
Nov 1, 2021 12:57
|
|
|
Poopernickel posted:The thing is, systemd isn't -one- thing. Poettering has said that he cares not one bit for portability or POSIX: Lennart Poettering in a 2011 interview at FOSDEM posted:In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving! SYSV Fanfic posted:It's way more than that list now. Many of the LSB Daemons have systemd alternatives. That's essentially what systemd has become, a LSB init/daemon replacement. The ports collection is a hierarchy of Makefiles and (usually) a few patches that get applied at build-time, in order to fix Linuxisms. However, since it was introduced in 1994, the ports collection has not needed a whole lot of patches (with a few exceptions) because until fairly recently, most software developers don't exclusively develop software for Linux, they developed software against the POSIX standard or try for some level of portability. The exception being Chromium, where upstream has consistently refused patchesfrom FreeBSD (or the others, but that one is the one I know the most about), for everything from proper higher-privilege enforced sandboxing (instead of the weak sandboxing shipped in Chromium by default) down to a lot of very minor files. That last part is just plain wrong. FreeBSD is consistently in the top-5 for projects with the most up-to-date third-party software with a lower percentage of outdated third-party software then the rest of the top-10. Even then, it's not entirely accurate as there's a lot more ports than it lists and secondly because its way of calculating what's potentially vulnerable isn't very accurate and freebsd at least has its own much more accurate system that's integrated into the packaging system itself via pkg-audit(8) - and unless it's changed, most Linux distributions don't provide an option for doing that out-of-the-box. Meanwhile, there are still Linux developers who're interested in portability - NFS interoperability accounts for a pretty good chunk of fixes that's gone in to the head of the FreeBSD tree in the last few months, as a result of the maintainers of NFS on Linux and FreeBSD actually working on interoperability, which proves that it's still possible and there's still a will. So the question becomes: Does software benefit from portability, or is it not worth it? There are pretty definitive reasons for portability; at a very minimum it ensures that should your security needs require it you can run your software on multiple kernels (VeriSign does this for their root servers, by running both Linux and FreeBSD to ensure that they can't get targeted as easily), but in addition to that it also forces developers to think more about the code more, and discourages lazy developer practices which lead to mistakes. Put another way, it makes things more secure and it makes programs objectively better. If those reasons aren't enough for it to be "worth it", I don't know what is. BlankSystemDaemon fucked around with this message at 13:39 on Nov 1, 2021 |
|
#
?
Nov 1, 2021 13:27
|
|
|
NihilCredo posted:Right, and distribution size is also a business issue. What even is the point of this analogy, one CD is cheaper than 13 floppies, of course they changed process. Consider instead how increases in RAM and CPU has led to a glorious revolution in efficient & responsive application design, no, wait, everything is Electron now. Mr. Crow posted:What are you even talking about. Literally nobody is arguing that business will do the bare minimum, of course they will. That doesn't change the fact there is a huge and material change going from an HDD to an SSD, which is what every game console has done this / last generation, and it is in fact "a game changer". It doesn't matter if the company spends zero effort optimizing loading its still going to load 10x faster at a minimum and by your own argument it doesn't matter if they're developing for a HDD why would they give a poo poo either way. GTA Online is famously and simultaneously the worst loading and the best selling game of all time, and they couldn't be assed to spend the afternoon with a profiler to fix one of the most notoriously simple bugs causing 10 minute load screens for nearly a decade. What "load optimization threshold" where they spending man hours on, exactly? The threshold there was they already had their user's money and could coast off of their user's putting up with any amount of bullshit because it had the GTA name.
|
|
#
?
Nov 1, 2021 14:25
|
|
|
SYSV Fanfic posted:What kind of embedded stuff do you guys work on? iiot gateways. ie, very slow telemetry and control protocols both wired (rs485,232, etc) and wireless (LoRa, BLE) to a wan, cellular or Ethernet. the problem with armv5 (arm9) is that software interrupts are slow as molasses so while you might think a 400mhz processor would be more than capable of a certain task you can certainly overload it very easily with threads. as a result a cortex-a5 at similar or lower speeds can handle tasks significantly faster because the interrupt controller is just so much faster. oh also software float. this would be fine (ish) except for the entire “run JavaScript on everything” movement. did you know node.js supported software fp until like 2018? hobbesmaster fucked around with this message at 14:37 on Nov 1, 2021 |
|
#
?
Nov 1, 2021 14:35
|
|
|
hobbesmaster posted:oh also software float. this would be fine (ish) except for the entire “run JavaScript on everything” movement. did you know node.js supported software fp until like 2018?
|
|
#
?
Nov 1, 2021 14:45
|
|
|
I recently saw an internal codebase with a runtime dependency on libsystemd, because its developer likes dbus IPC but only likes the systemd wrapper around it. This program runs on Buildroot, has nothing to do with init and doesn't interact with systemd in any way. Portability in our business-critial software? Why would we ever need that????? It'll be easy to pin the version right? Poopernickel fucked around with this message at 16:15 on Nov 1, 2021 |
|
#
?
Nov 1, 2021 16:02
|
|
|
BlankSystemDaemon posted:However, since it was introduced in 1994, the ports collection has not needed a whole lot of patches (with a few exceptions) because until fairly recently, most software developers don't exclusively develop software for Linux, they developed software against the POSIX standard or try for some level of portability. I remember the 90s and: laffo.
|
|
#
?
Nov 1, 2021 16:55
|
|
|
Poopernickel posted:I recently saw an internal codebase with a runtime dependency on libsystemd, because its developer likes dbus IPC but only likes the systemd wrapper around it. If it runs on Buildroot, then pinning the Buildroot version is how you pin the version? Not seeing an issue here.
|
|
#
?
Nov 1, 2021 17:18
|
|
|
When we want to go upgrade buildroot to a newer version, systemd is gonna change versions. Multiple versions of libsystemd also don't coexist nicely because of all the IPC. Hope the team that owns that code is ready for a nightmare of compatibility testing every year forever. edit: oh, and also the target config doesn't use systemd-init for ~*ReAsOnZ*~  , and Buildroot has no built-in ability to say "I want libsystemd without the rest of systemd" because that's dumb as hell
Poopernickel fucked around with this message at 18:21 on Nov 1, 2021 |
|
#
?
Nov 1, 2021 18:17
|
|
|
|
| # ? Jun 2, 2024 14:51 |
|
|
Poopernickel posted:When we want to go upgrade buildroot to a newer version, systemd is gonna change versions. Multiple versions of libsystemd also don't coexist nicely because of all the IPC. You can create a post-build script to remove everything except libsystemd, or you could modify the package/systemd/systemd.mk file to do what you want.  I've updated systemd multiple times on the project I work on at work that also happens to use Buildroot + systemd and it's never broken in odd ways. Edit* Also, Buildroot LTS versions have support for 2 years. Double Edit* You could also just patch Buildroot to use the older version of systemd. FlapYoJacks fucked around with this message at 18:30 on Nov 1, 2021 |
|
#
?
Nov 1, 2021 18:26
|
|