|
arm64 does actually have instructions that are defined as having exactly the right semantics for javascript’s floating-point min/max
|
#
?
Jun 15, 2018 03:13
|
|
|
|
| # ? May 17, 2024 14:55 |
|
|
rjmccall posted:arm64 does actually have instructions that are defined as having exactly the right semantics for javascript’s floating-point min/max ah yes, the classic "fjcvtzs". does JavaScriptCore even support that? ARM team really wants to save money I guess, can't even afford to buy a vowel
|
|
#
?
Jun 15, 2018 04:41
|
|
|
oh i totally forgot which operation it was, oops. that is way more useful than min/max afaik there are no production chips supporting armv8.3 yet, so no, i doubt there are any js implementations that will take advantage of it if available
|
|
#
?
Jun 15, 2018 05:05
|
|
|
i am glad that everybody calls it "arm64" instead of its asinine official moniker
|
|
#
?
Jun 15, 2018 05:41
|
|
|
Sapozhnik posted:i am glad that everybody calls it "arm64" instead of its AAsinine official moniker
|
|
#
?
Jun 15, 2018 06:13
|
|
|
Suspicious Dish posted:ARM team really wants to save money I guess, can't even afford to buy a vowel at least it isn't power??
|
|
#
?
Jun 15, 2018 08:05
|
|
|
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArch
|
|
#
?
Jun 16, 2018 02:36
|
|
|
Acorn RISC Machine
|
|
#
?
Jun 16, 2018 02:50
|
|
|
wow, a proposal to make exceptions unnecessary for the standard library and a proposal to make throws magically turn into a return of an invisible optional C++ is goin' places!
|
|
#
?
Jun 17, 2018 19:12
|
|
|
the exceptions proposal is basically proposing adding swift's error handling system
|
|
#
?
Jun 17, 2018 20:04
|
|
|
where are these proposals?
|
|
#
?
Jun 17, 2018 20:22
|
|
|
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf
|
|
#
?
Jun 17, 2018 20:52
|
|
|
oh god the interoperation bits are so complicated but yeah this pretty closely parallels my analysis herb (being herb) is really attached to the idea that he has to specify implementation-level stuff like how it works at the abi level also lol at this actually happening
|
|
#
?
Jun 17, 2018 21:53
|
|
|
somebody should tell herb that the reason nobody uses exceptions is that they wrote a bunch of C++ code that used existing exception unsafe C code and then they wrote a bunch of C++ code that used the existing exception unsafe C++ code and nobody actually cares about overhead or non-determinism
|
|
#
?
Jun 17, 2018 22:12
|
|
|
there absolutely are people who do not use exceptions on greenfield projects because they care about the overhead
|
|
#
?
Jun 17, 2018 23:21
|
|
|
lol game development. although the support for exceptions on consoles has historically been hilariously bad, so that's probably a big part of the reason also what overhead is there on modern architectures when you're not actually triggering exceptions? i swear i used to know this but i've been in .net land for some time now and i'm starting to forget about c++
|
|
#
?
Jun 17, 2018 23:39
|
|
|
Deep Dish Fuckfest posted:lol game development. although the support for exceptions on consoles has historically been hilariously bad, so that's probably a big part of the reason they go over it in the paper but it bloats your binaries by like 15% and it’s worth noting that even if you’re not writing code that throws exceptions you can still be using code that does, because you can link in libraries and stuff. and then they’ll have all the problems like unbounded rtti lookups even if you don’t do it yourself
|
|
#
?
Jun 17, 2018 23:42
|
|
|
Deep Dish Fuckfest posted:i'm starting to forget about c++ it's for the best, really
|
|
#
?
Jun 18, 2018 01:34
|
|
|
my favorite thing I've found so far is the GOG Galaxy client library, which uses exceptions as part of normal API usage for some loving reason, meaning you can't turn them off since you have to have them to use them from its stupid DLL
|
|
#
?
Jun 18, 2018 03:31
|
|
|
Deep Dish Fuckfest posted:lol game development. although the support for exceptions on consoles has historically been hilariously bad, so that's probably a big part of the reason with the itamium approach to exceptions they have zero runtime overhead when not thrown which owns for errors which should never happen, but they add nontrivial size bloat and are mind-bogglingly slow when they do happen, so they're unsuitable for things like "try this operation which has a good chance of failing and report why it failed if so"
|
|
#
?
Jun 18, 2018 06:09
|
|
|
Plorkyeran posted:with the itamium approach to exceptions they have zero runtime overhead when not thrown which owns for errors which should never happen, but they add nontrivial size bloat and are mind-bogglingly slow when they do happen, so they're unsuitable for things like "try this operation which has a good chance of failing and report why it failed if so" that's the correct approach to exceptions
|
|
#
?
Jun 18, 2018 08:35
|
|
|
the correct approach is to return a Result<T, E> :functionalsay:
|
|
#
?
Jun 18, 2018 08:49
|
|
|
actually I think you’ll find the correct approach is restartable conditions as implemented by Common Lisp
|
|
#
?
Jun 18, 2018 11:00
|
|
|
instead of setting up an elaborate error handling scheme that introduces tons of control flow that is rarely if ever fully tested, you should just optimize your code for the happy path and, if an error does happen, immediately terminate the cloud vm it's running on and create a new one to start over
|
|
#
?
Jun 18, 2018 11:33
|
|
|
exceptions are pretty good, but handling exceptions is bad. so agreed with above
|
|
#
?
Jun 18, 2018 12:11
|
|
|
Vanadium posted:instead of setting up an elaborate error handling scheme that introduces tons of control flow that is rarely if ever fully tested, you should just optimize your code for the happy path and, if an error does happen, immediately terminate the cloud vm it's running on and create a new one to start over i want to subscribe to your newsletter
|
|
#
?
Jun 18, 2018 12:19
|
|
|
what if you’re writing software that runs on things people actually use rather than on a server
|
|
#
?
Jun 18, 2018 18:46
|
|
|
eschaton posted:what if you’re writing software that runs on things people actually use rather than on a server make it a service
|
|
#
?
Jun 18, 2018 18:47
|
|
|
eschaton posted:what if you’re writing software that runs on things people actually use rather than on a server ON ERROR RESUME NEXT
|
|
#
?
Jun 18, 2018 18:49
|
|
|
cinci zoo sniper posted:make it a service microservices all the way down. no clients no masters. there isn’t any way for consumers to access anything from their devices, but that’s probably for the best really
|
|
#
?
Jun 18, 2018 18:52
|
|
|
software that people use is bad software that other software uses is the best
|
|
#
?
Jun 18, 2018 19:04
|
|
|
i demand at least 5 layers of software between anything i touch and anything people actually use
|
|
#
?
Jun 18, 2018 19:26
|
|
|
errors are values imo
|
|
#
?
Jun 18, 2018 19:35
|
|
|
redleader posted:the correct approach is to return a Result<T, E> :functionalsay: rt4 posted:errors are values imo i agree with these posts
|
|
#
?
Jun 18, 2018 20:55
|
|
|
would you make a division by zero error an explicit value though
|
|
#
?
Jun 18, 2018 21:07
|
|
|
comedyblissoption posted:would you make a division by zero error an explicit value though you mean like in ieee 754?
|
|
#
?
Jun 18, 2018 21:31
|
|
|
comedyblissoption posted:would you make a division by zero error an explicit value though you mean like ERR_DIVBY0_FUCK?
|
|
#
?
Jun 18, 2018 21:35
|
|
|
so when i skimmed this last night, i came away with the impression that herb was proposing that functions could either throw std::error as a standard type-erased exception type or declare that they throw a specific concrete exception type. a coworker pointed out today that i had this wrong and that in fact the only option was the type-erased std::error. rereading the proposal, i realized that what led me astray is this nice little swipe at the swift error-handling design: quote:Learning from the variety of error handling methods in Objective-C (described in a nutshell in the first 10 minutes of [Squires 2017]), Swift decided to pursue an always-untyped boolean throws, which is understandable but in my opinion overcorrects on the opposite side (and there are ongoing recurring calls to add a typed throws and/or a Result type to Swift, with sympathy from key participants including Chris Lattner). This proposal allows throwing rich values (not just boolean success/fail like C++ noexcept or Swift throws) that are able to represent all the same errors that types are used to represent in languages that throw typed exceptions (including today’s C++), by throwing a well-known common type rather than arbitrary types. which in retrospect is quite explicit about herb's apparent belief that swift literally has no error types and only allows a no-operand throw (swift uses a type-erased Error type exactly analogous to herb's proposed std::error)
|
|
#
?
Jun 19, 2018 03:28
|
|
|
openBSD giving up on Intel SMT lol
|
|
#
?
Jun 19, 2018 23:15
|
|
|
|
| # ? May 17, 2024 14:55 |
|
|
JawnV6 posted:openBSD giving up on Intel SMT lol eh adding a tunable to turn it on and off doesn't sound too bad
|
|
#
?
Jun 20, 2018 00:27
|
|