ChanServ changed the topic of #elliottcable to: drugs
<whitequark>
give me a min in C++, and, um, someone who wrote more than zero lines of haskell, ie, not me, will show you an equivalent haskell code
<alexgord_>
the basic list type of C++ is std::vector, or perhaps std::array
<whitequark>
the basic collection type.
<alexgord_>
whatever :P
<whitequark>
the basic collection type in both C++ and haskell is whatever the user wants it to be
<whitequark>
it's not like
<whitequark>
javascript
<whitequark>
where it HAS to be either array or has
<whitequark>
*hash
<alexgord_>
maybe, anyway my point was more that in C++ you can specialize it to death, also you can use pointers for types that are expensive to copy but assignment for types which are cheap (like ints)
<alexgord_>
you can maybe do all that in rust, definitely not in haskell
<whitequark>
in rust, yeah
<whitequark>
haskell jumps over itself to distance you from anything remotely close to machine
<alexgord_>
but it's interesting that in many languages you can't implement min() really efficiently over lots of types. it's such a simple function
<alexgord_>
just shows how far we have to go
<alexgord_>
in terms of designing languages
<whitequark>
I don't know, not all languages have efficiency as its end goal
<whitequark>
more specifically, CPU efficiency
<alexgord_>
they should!
<whitequark>
and RAM
<whitequark>
why?
<whitequark>
we have exponentially growing amounts of them
<alexgord_>
because the intel people are working day and night to get us faster CPUs
<alexgord_>
and we squander them on node.js and python scripts
<whitequark>
nope, they're working to give us more CPUs
<alexgord_>
better performing CPUs?
<whitequark>
no, more CPUs at this point
<whitequark>
CPU cores
<alexgord_>
I'm sure they are getting faster
<whitequark>
they're not
<alexgord_>
doesn't the process shrinkage make them faster?
<whitequark>
right now we bumped into yet another set of limits
<whitequark>
for one, today's CPUs often can't run faster because of power budget. it is not physically possible to dissipate that much heat, therefore the CPU is forced to scale down
<whitequark>
well, basically, most new silicon goes to caches
<alexgord_>
well I'm counting bigger caches as "faster"
<whitequark>
then: today's cores spend vast majority of their time waiting for memory
<alexgord_>
less time spent going to RAM = faster
<alexgord_>
yah
<alexgord_>
which is kinda silly :P
<whitequark>
and CPU efficiency of min() has no effect whatsoever on its observed performance if your language only uses "objects" and each "object" has a header of like 40 bytes
<alexgord_>
well... avoiding copies is important, and avoiding cache misses
<alexgord_>
the two are antagonistic though
<whitequark>
it's not really silly, it's... lightspeed
<whitequark>
a CPU core is tiny and closely coupled, it's basically an optimum for high clock frequency
<alexgord_>
haskell avoids copies very well, by using linked lists everywhere. But it pays in terms of cache misses
<whitequark>
well, yeah, linked lists are a cache disaster
<alexgord_>
whitequark: it could be doing something else while it's waiting for RAM though
<alexgord_>
whitequark: glad we can agree on something LOL
<purr>
LOL
<eligrey>
imagine 1/4th the volume and surface area and ring sized
<eligrey>
and only powering nfc
<eligrey>
that could easily reach 4 months or more
<whitequark>
Bluetooth LE*
<whitequark>
has no relationship whatsoever to Bluetooth except its name
<eligrey>
bluetooth le uses a lot more energy than nfc reading
<whitequark>
that's a strong assumption I'm not sure about
<whitequark>
it uses 2.4G instead of 10M... and higher frequencies usually let you have a transceiver with much less power
<whitequark>
not to mention the fact that both nodes are powered means there's no power wasted in transmission
<whitequark>
alexgord_: well like what
<eligrey>
active bluetooth LE is at minimum 14mA
<eligrey>
from the battery
<eligrey>
not output from antenna
<whitequark>
eligrey: that says... nothing
<whitequark>
what's consumed energy per single transmission? for BLE and NFC
<whitequark>
transaction*
<eligrey>
i'm saying that tag actively broadcasts bluetooth le for 6 months
<eligrey>
and nfc uses even less energy
<whitequark>
source?
<eligrey>
simple facts
<alexgord_>
whitequark: I dunno really. maybe the answer is better prefetching. We certainly have enough memory bandwidth, it's latency that's the problem
<eligrey>
ill google for nfc power usage
<whitequark>
do you understand that your 14mA number is meaningless?
<alexgord_>
(and languages not using silly data structures like linked lists)
<whitequark>
14mA for 1s is a shitton. 14mA for 100us is nothing.
<whitequark>
alexgord_: well no shit
<eligrey>
the wikipedia page says <15mA
<whitequark>
I would say that the answer is FeRAM
<whitequark>
because latency today is fundamentally capped by DRAM
<alexgord_>
whitequark: oh and smaller code size (which C++ doesn't really help)
<eligrey>
wow that setup time
<eligrey>
ok nvm
* eligrey
buys a bluetooth le ring instead
<whitequark>
like, all the new DDRx busses mainly improve *bus* speed and utilize same old slow banks with wider and wider data busses
<whitequark>
inside the module
<whitequark>
cheating basically
<whitequark>
eligrey: setup time?
<eligrey>
im imaginging it having to be active for much longer if setup takes that long
<eligrey>
anyways bluetooth LE is always on and the nfc reader in this isnt
<whitequark>
well it's not "always on", that's the point of it
<eligrey>
assuming 3 seconds per gesture thats less than an hour of total active use
<whitequark>
look at how BLE actually works, it's only LE because it transmits data in tiny bursty packets AND does it only if it absolutely needs to
<whitequark>
if it's about gestures, I'd expect the sensor circuitry to draw more energy
<eligrey>
no im not trying to say my ring would have gestures
<eligrey>
btw my smart fistbump rings only transmit data in bursts as well
<eligrey>
the one-time burst at a fist bump
<eligrey>
once per bump
<whitequark>
1000 bumps. at this usage pattern it is more likely to be limited by self-discharge of the battery
<whitequark>
so... no more than 6 months, likely much less
<whitequark>
*shrug*
<purr>
¯\(º_o)/¯
<whitequark>
honestly, screw electronics. I think we only should actively move pointless physical things to electronic ones
<whitequark>
like paperwork and shit
<eligrey>
i'm not saying that i would get that ring gesture thing
<eligrey>
that sounds really dumb and has terrible life
<whitequark>
if it's remotely worthwhile, make sure it doesn't need a fucking battery
<eligrey>
battery life*
<whitequark>
like what the fuck, a caliper with a battery
<eligrey>
myo bands on the other hand...
<whitequark>
myo?
<whitequark>
oh btw
<whitequark>
if you have like an elastic silicone band
<whitequark>
you can make it gain power from deformation
<whitequark>
that's actually a decent amount of power it will gather just from you mildlessly fondling that
<whitequark>
*mindlessly
<eligrey>
in the future we'll all get skin cancer but our devices will never need charging due to the power and surveillance lasers that will shoot at you 24/7
<eligrey>
ignore that part about surveillance lasers
<eligrey>
idk what you could surveill with a laser
<whitequark>
lasers?
<whitequark>
how would you power things with a laser
<eligrey>
the main point was power lasers
<whitequark>
that's extremely complicated
<whitequark>
use, like, inductive coupling
<eligrey>
poes law pls
<whitequark>
it's shit too though
<eligrey>
whitequark is unable to detect sarcasm :S
<whitequark>
I am
<whitequark>
and guess why?
<whitequark>
1) because I can't hear your voice or see your facial expression via the internet
<whitequark>
2) because on internet, I can never know whether you're *that* dumb or being sarcastic. I err on the safe side.
<eligrey>
oh that's just your fault for not watching my 24/7 facestream
<whitequark>
link
<eligrey>
unfortunately it's a pay service
<eligrey>
but it is live!
<eligrey>
whitequark: also you need to pay per frame, and pay before recieving the frame
<eligrey>
lighting is also extra so by default all you get is a black image
<eligrey>
whitequark: do i watch the anime first or the ova
<eligrey>
idk i always thought pv was promotional video
<whitequark>
oh
<whitequark>
so, fanservice
<whitequark>
I guess watch anime first
<eligrey>
ill start on episode 1 instead of the ova
<eligrey>
k
Sgeo has joined #elliottcable
eligrey_ has joined #elliottcable
eligrey has quit [Ping timeout: 245 seconds]
ELLIOTTCABLE_ has joined #elliottcable
ELLIOTTCABLE has quit [Ping timeout: 240 seconds]
ec has quit [Ping timeout: 240 seconds]
ELLIOTTCABLE_ is now known as ELLIOTTCABLE
ec has joined #elliottcable
nuck has quit [Ping timeout: 240 seconds]
PLejeck has joined #elliottcable
<purr>
<alexgordon> ELLIOTTCABLE actually has only one sperm, but it is very effective
<devyn>
whitequark: linked lists are not required in Haskell; they're just convenient because they're a very simple way of chaining items together indefinitely
<devyn>
:p
<devyn>
and so that's why they're the primary collection type
<devyn>
same reason Lisp likes them, really
<devyn>
elegant and simple
<devyn>
oops
<devyn>
I meant alexgord_
<devyn>
not whitequark
<alexgord_>
devyn: I disagree
<alexgord_>
devyn: even if YOU don't use linked lists, any libraries you use WILL
<devyn>
well, no, only when it doesn't really matter
<alexgord_>
plus it takes an awful lot of work to use haskell without using linked lists
<devyn>
well collection literals generally get constructed with whatever fromList function
<devyn>
like Data.Set.fromList
<devyn>
it's kinda silly to not use linked lists at all
<devyn>
there's nothing wrong with them inherently; they're just slow for (a lot) of different applications
<devyn>
and the 'indefinite' property of a linked list is kind of important; being able to have infinite lists is a nice feature
alexgord_ has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
yorick has quit [Remote host closed the connection]