<kares[m]>
updated RGs 3.1 PR for a potential 9.2.18.0 - all 🟢
<kares[m]>
updated RGs 3.1 PR for a potential 9.2.18.0 - all 🟢
olleolleolle has quit [Ping timeout: 265 seconds]
olleolleolle has quit [Ping timeout: 265 seconds]
olleolleolle has joined #jruby
olleolleolle has joined #jruby
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
drbobbeaty has joined #jruby
drbobbeaty has quit [Read error: No route to host]
drbobbeaty has quit [Read error: No route to host]
drbobbeaty has joined #jruby
drbobbeaty has joined #jruby
<headius[m]>
kares sounds great... And I have a surprise for .18 as well I wish could be in .17: native support for Apple Silicon
<headius[m]>
kares sounds great... And I have a surprise for .18 as well I wish could be in .17: native support for Apple Silicon
<headius[m]>
Finally figured out which libffi patches to include for jffi to build last night, will do jnr stack releases today and a PR for .18+
<headius[m]>
Finally figured out which libffi patches to include for jffi to build last night, will do jnr stack releases today and a PR for .18+
<headius[m]>
Hopeful .18 will be light and stable enough we can finally make 9.3 the next release
<headius[m]>
Hopeful .18 will be light and stable enough we can finally make 9.3 the next release
<enebo[m]>
kares: do we know what things are fixed in the RG update?
<enebo[m]>
kares: do we know what things are fixed in the RG update?
<enebo[m]>
I see some extra mutex protection. some changed detection for what is linux
<enebo[m]>
I see some extra mutex protection. some changed detection for what is linux
<headius[m]>
I don't know of any fixes we need per se but it does bother me that we ship a pretty old version
<headius[m]>
I don't know of any fixes we need per se but it does bother me that we ship a pretty old version
<headius[m]>
Not enough to ram it into 17 though
<headius[m]>
Not enough to ram it into 17 though
<enebo[m]>
new PEM for rubygems.org
<enebo[m]>
new PEM for rubygems.org
<kares[m]>
there's a certificate update
<kares[m]>
there's a certificate update
<headius[m]>
At least rvm upgrades ruby gems I believe. Not sure if any of the others do
<headius[m]>
At least rvm upgrades ruby gems I believe. Not sure if any of the others do
<headius[m]>
GHA setup-ruby does I think
<headius[m]>
GHA setup-ruby does I think
<enebo[m]>
headius: so you are saying we are running with this version in CI envs already because they install it?
<enebo[m]>
headius: so you are saying we are running with this version in CI envs already because they install it?
<headius[m]>
I am pretty sure, yes. We get reports about breakages in new rubygems releases having not upgraded in many months
<headius[m]>
I am pretty sure, yes. We get reports about breakages in new rubygems releases having not upgraded in many months
<enebo[m]>
for rvm I suppose many peoples dev envs
<enebo[m]>
for rvm I suppose many peoples dev envs
<headius[m]>
That could be people manually updating, but usually they link to a CI build
<headius[m]>
That could be people manually updating, but usually they link to a CI build
<enebo[m]>
My obvious pushback here is mostly putting in a 118 file changeset minutes before we put out a release
<enebo[m]>
My obvious pushback here is mostly putting in a 118 file changeset minutes before we put out a release
<headius[m]>
I don't think we have any bugs preventing manual updates
<headius[m]>
I don't think we have any bugs preventing manual updates
<enebo[m]>
We can do some basic personal testing here to make sure nothing obvious is broken on our platforms
<enebo[m]>
We can do some basic personal testing here to make sure nothing obvious is broken on our platforms
<headius[m]>
If any of the updates fix security issues I would say we don't have a choice
<enebo[m]>
The updated certificate could be important too
<headius[m]>
If any of the updates fix security issues I would say we don't have a choice
<enebo[m]>
The updated certificate could be important too
<headius[m]>
Yeah
<headius[m]>
Yeah
<enebo[m]>
So I am not dismissing this out of hand but it feels a little sketchy
<enebo[m]>
So I am not dismissing this out of hand but it feels a little sketchy
<enebo[m]>
My main fear at this point would be something we cannot see on an esoteric platform or that it hits some TLS/SSL-like problem we won't do unless we do something less common like push a gem
<enebo[m]>
My main fear at this point would be something we cannot see on an esoteric platform or that it hits some TLS/SSL-like problem we won't do unless we do something less common like push a gem
<enebo[m]>
We can just share this humiliation if we go forward too :)
<enebo[m]>
We can just share this humiliation if we go forward too :)
drbobbeaty has quit [Read error: No route to host]
drbobbeaty has quit [Read error: No route to host]
<kares[m]>
haven't checked but I do not think the old certificates are invalid - should still work (some are redundant - unused but the main CA should still be valid)
<kares[m]>
haven't checked but I do not think the old certificates are invalid - should still work (some are redundant - unused but the main CA should still be valid)
<enebo[m]>
headius: I don't care about your jffi for mac hardware update because I don't think it will affect anyone
<enebo[m]>
headius: I don't care about your jffi for mac hardware update because I don't think it will affect anyone
<enebo[m]>
headius: with that said I don't really see any reason to put it into .18 and not 9.3
<enebo[m]>
headius: with that said I don't really see any reason to put it into .18 and not 9.3
<kares[m]>
enebo: Logstash is pretty interested in the FFI fixes, just haven't made noise around it 😜
<kares[m]>
enebo: Logstash is pretty interested in the FFI fixes, just haven't made noise around it 😜
<enebo[m]>
kares: for mac hardware?
<enebo[m]>
kares: for mac hardware?
<headius[m]>
FFI fixes?
<headius[m]>
FFI fixes?
drbobbeaty has joined #jruby
drbobbeaty has joined #jruby
<kares[m]>
ssory I mean native support through JNR
<kares[m]>
ssory I mean native support through JNR
<kares[m]>
that should fix ARM64 right?
<kares[m]>
that should fix ARM64 right?
<enebo[m]>
kares: you know if logstash is being tested against master?
<enebo[m]>
kares: you know if logstash is being tested against master?
<kares[m]>
nope
<kares[m]>
nope
<enebo[m]>
kares: I would like to see us work at .0 for them to stop this poor experience of them having to wait a dozen point releases
<enebo[m]>
kares: I would like to see us work at .0 for them to stop this poor experience of them having to wait a dozen point releases
<enebo[m]>
I would also like to advance customers off older branches quicker
<enebo[m]>
I would also like to advance customers off older branches quicker
<kares[m]>
me too - it's just that I am not allowed to work on stuff that isn't 'blessed' by the team
<kares[m]>
me too - it's just that I am not allowed to work on stuff that isn't 'blessed' by the team
<enebo[m]>
kares: next standup or chance you have to talk to them point out we are willing to help a bit with any 9.3 issues they discover
<kares[m]>
such as testing against jruby-head --- you know corporate priorities
<kares[m]>
such as testing against jruby-head --- you know corporate priorities
<enebo[m]>
kares: next standup or chance you have to talk to them point out we are willing to help a bit with any 9.3 issues they discover
<kares[m]>
okay I'll bring it up but I am afraid there's too much work planned already ...
<kares[m]>
okay I'll bring it up but I am afraid there's too much work planned already ...
<enebo[m]>
mostly we are hoping to see if ci output shows different issues or not
<enebo[m]>
mostly we are hoping to see if ci output shows different issues or not
<enebo[m]>
ignorable ci job and some liason to just point out we are not passing would make us feel a lot better about 9.3.0
<enebo[m]>
ignorable ci job and some liason to just point out we are not passing would make us feel a lot better about 9.3.0
<kares[m]>
the problem here it's not smt like just adding: `rvm: jruby-head`
<kares[m]>
the problem here it's not smt like just adding: `rvm: jruby-head`
<enebo[m]>
kares: ok so ci is not rigged up for following a branch
<enebo[m]>
kares: ok so ci is not rigged up for following a branch
<enebo[m]>
kares: I guess if you can signal what we want maybe they will do something. As it stands we just do our best. Once we added sequel ci we ended up finding a number of non-covered issues
<enebo[m]>
kares: I guess if you can signal what we want maybe they will do something. As it stands we just do our best. Once we added sequel ci we ended up finding a number of non-covered issues
<kares[m]>
yy they were initially hoping JRuby would do that - run the LS suite
<kares[m]>
yy they were initially hoping JRuby would do that - run the LS suite
<headius[m]>
kares: new jffi will fix Apple arm64 support, yes
<headius[m]>
kares: new jffi will fix Apple arm64 support, yes
<headius[m]>
I see no reason we shouldn't be as green on Apple Silicon after that as we are on any x86 platform
<headius[m]>
I see no reason we shouldn't be as green on Apple Silicon after that as we are on any x86 platform
<kares[m]>
that is also tricky since it's neither a Java suite nor a typical Ruby one ... it makes sense to do it the other way around
<kares[m]>
that is also tricky since it's neither a Java suite nor a typical Ruby one ... it makes sense to do it the other way around
<headius[m]>
I suppose there are logstashers with M1 machines now
<headius[m]>
I suppose there are logstashers with M1 machines now
<kares[m]>
yes
<kares[m]>
yes
<enebo[m]>
headius: and that PR will just be adding the support right? No other fixes mixes in?
<enebo[m]>
headius: and that PR will just be adding the support right? No other fixes mixes in?
<headius[m]>
FWIW the rest of jnr fixes are pretty benign
<headius[m]>
FWIW the rest of jnr fixes are pretty benign
<headius[m]>
enebo: can
<headius[m]>
enebo: can
<enebo[m]>
haha
<enebo[m]>
haha
<headius[m]>
can't
<headius[m]>
can't
<headius[m]>
we can't just upgrade jffi
<headius[m]>
we can't just upgrade jffi
<headius[m]>
due to dependency convergence that someone reports EVERY time we stray (which is why we check it in CI now)
<headius[m]>
due to dependency convergence that someone reports EVERY time we stray (which is why we check it in CI now)
<enebo[m]>
alright so we need to look at each fix before we merge this
<enebo[m]>
alright so we need to look at each fix before we merge this
<enebo[m]>
If they benign then it won't be too bad just to discuss what risks may be there or not
<enebo[m]>
If they benign then it won't be too bad just to discuss what risks may be there or not
<headius[m]>
I would not have jffi+ done until late this morning or early afternoon at best
<headius[m]>
I would not have jffi+ done until late this morning or early afternoon at best
<headius[m]>
fix audits should be quick though
<headius[m]>
fix audits should be quick though
<enebo[m]>
ok here is an alternate proposal
<enebo[m]>
ok here is an alternate proposal
<headius[m]>
I feel your pain... would be nice to get a more "done" release out for 9.2.x
<headius[m]>
I feel your pain... would be nice to get a more "done" release out for 9.2.x
<enebo[m]>
we release next monday and land both things today/tomorrow
<enebo[m]>
we release next monday and land both things today/tomorrow
<headius[m]>
but don't want to require another one unnecessarily
<headius[m]>
but don't want to require another one unnecessarily
<enebo[m]>
some due diligence has to be done to scrutinize whether we broke anytrhing
<enebo[m]>
some due diligence has to be done to scrutinize whether we broke anytrhing
<headius[m]>
that would be fine with me... maybe we can get some users like kalenp jswenson to check out a snapshot
<headius[m]>
that would be fine with me... maybe we can get some users like kalenp jswenson to check out a snapshot
<enebo[m]>
I would prefer to be a week later and not have this 10s to blastoff dilemma
<enebo[m]>
I would prefer to be a week later and not have this 10s to blastoff dilemma
<headius[m]>
changing the o-rings on the booster at T minus 5
<headius[m]>
changing the o-rings on the booster at T minus 5
<enebo[m]>
I don't think we are very risky people so it is not like I am doubting these will run into problems but if they do I will feel dumb
<enebo[m]>
I don't think we are very risky people so it is not like I am doubting these will run into problems but if they do I will feel dumb
<headius[m]>
is it too soon for Challenger jokes?
<headius[m]>
is it too soon for Challenger jokes?
<enebo[m]>
I was in high school and a friend walked up to me and told me. He had this look of shock
<enebo[m]>
I was in high school and a friend walked up to me and told me. He had this look of shock
<enebo[m]>
Then we got to see it blow up about 600 times more in the next week
<enebo[m]>
Then we got to see it blow up about 600 times more in the next week
<enebo[m]>
but yeah it has been long enough
<enebo[m]>
but yeah it has been long enough
<headius[m]>
I was in grade school and didn't find out until I got home. We were supposed to watch "the lesson" in class but launch delays meant we had to return to class
<headius[m]>
I was in grade school and didn't find out until I got home. We were supposed to watch "the lesson" in class but launch delays meant we had to return to class
<headius[m]>
I will never look at o-rings the same way
<headius[m]>
I will never look at o-rings the same way
<enebo[m]>
It was about as covered as 9/11 at that time and network tv was still main info source so it was pretty surreal
<enebo[m]>
It was about as covered as 9/11 at that time and network tv was still main info source so it was pretty surreal
<headius[m]>
yeah very similar
<headius[m]>
yeah very similar
<headius[m]>
ok I will put finishing touches on Apple arm64 stuff and spin releases and a PR today
<headius[m]>
ok I will put finishing touches on Apple arm64 stuff and spin releases and a PR today
<headius[m]>
fingers crossed everything just works
<headius[m]>
fingers crossed everything just works
<enebo[m]>
headius: ok.
<enebo[m]>
headius: ok.
<enebo[m]>
kares: I saw nothing stick out as weird in your PR but it is just updating a gem. I loved seeing .tap(GEM::UNTAINT)
<enebo[m]>
kares: I saw nothing stick out as weird in your PR but it is just updating a gem. I loved seeing .tap(GEM::UNTAINT)
<enebo[m]>
I am missing an ampersand but I am not used to people using tap
<enebo[m]>
I am missing an ampersand but I am not used to people using tap
<enebo[m]>
I personally love tap for removing a = foo; a.bar; a as a pattern
<enebo[m]>
I personally love tap for removing a = foo; a.bar; a as a pattern
<kares[m]>
yy I use `tap` a lot as well
<kares[m]>
yy I use `tap` a lot as well
<kares[m]>
correct that PR is just running `update_rubygems` ... it also installs bundler but we purposefully not include that for 9.2
<kares[m]>
correct that PR is just running `update_rubygems` ... it also installs bundler but we purposefully not include that for 9.2
<headius[m]>
oh one risk on the apple silicon stuff (really need a better short name for that hardware family) is that these patches to make FFI work have not yet been landed in libffi/libffi
<headius[m]>
oh one risk on the apple silicon stuff (really need a better short name for that hardware family) is that these patches to make FFI work have not yet been landed in libffi/libffi
<kares[m]>
there's a separate PR for updating RGs (removing versioned files) on master
<kares[m]>
there's a separate PR for updating RGs (removing versioned files) on master
<headius[m]>
they only exist on atgreen's repo, one of the primary maintainers
<headius[m]>
they only exist on atgreen's repo, one of the primary maintainers
<enebo[m]>
headius: so we may release before they do?
<enebo[m]>
headius: so we may release before they do?
<headius[m]>
yes
<headius[m]>
yes
<headius[m]>
it has been slow going getting libffi AS fixes upstreamed, or so it seems
<headius[m]>
it has been slow going getting libffi AS fixes upstreamed, or so it seems
drbobbeaty has quit [Read error: No route to host]
drbobbeaty has quit [Read error: No route to host]
<headius[m]>
returnDefaultF128HighPrecision
<headius[m]>
returnDefaultF128HighPrecision
<headius[m]>
heh... ARM can't do 128bits can it?
<headius[m]>
heh... ARM can't do 128bits can it?
<headius[m]>
hmm it can
<headius[m]>
hmm it can
drbobbeaty has joined #jruby
drbobbeaty has joined #jruby
<headius[m]>
looks like a test bug... arm64 must be treating long double as 64 bit
<headius[m]>
looks like a test bug... arm64 must be treating long double as 64 bit
<headius[m]>
or at least it is not the preferred portable type for float128
<headius[m]>
or at least it is not the preferred portable type for float128
<headius[m]>
ahh not 64, 80
<headius[m]>
ahh not 64, 80
<headius[m]>
ok that explains it... Apple Silicon does not support 80-bit doubles... long double is 64-bits as I figured
<headius[m]>
ok that explains it... Apple Silicon does not support 80-bit doubles... long double is 64-bits as I figured
<headius[m]>
enebo: maybe I punt this test for now
<headius[m]>
enebo: maybe I punt this test for now
<enebo[m]>
sure? I guess I wonder how all that jives with code that will call it but it will work as it works so the test is not clever enough to test for a platforms size
<enebo[m]>
sure? I guess I wonder how all that jives with code that will call it but it will work as it works so the test is not clever enough to test for a platforms size
<enebo[m]>
I mean "long double" is just like your opinion man
<enebo[m]>
I mean "long double" is just like your opinion man
<headius[m]>
yeah I guess there is just no way to make this test pass without linking in a software float128 library, which pretty much defeats the purpose of the tst
<headius[m]>
yeah I guess there is just no way to make this test pass without linking in a software float128 library, which pretty much defeats the purpose of the tst
<headius[m]>
I will exclude it and file a bug
<headius[m]>
I will exclude it and file a bug
<headius[m]>
good news then is that jffi Apple arm64 is green
<headius[m]>
good news then is that jffi Apple arm64 is green
<enebo[m]>
yay
<enebo[m]>
yay
drbobbeaty has quit [Ping timeout: 264 seconds]
drbobbeaty has quit [Ping timeout: 264 seconds]
snickers has joined #jruby
snickers has joined #jruby
<headius[m]>
enebo: this does mean a recent xcode will be required since it builds a single fat binary
<headius[m]>
enebo: this does mean a recent xcode will be required since it builds a single fat binary
<headius[m]>
oh lovely... it also means I need to update macOS
<headius[m]>
oh lovely... it also means I need to update macOS
<enebo[m]>
yay
<enebo[m]>
yay
drbobbeaty has joined #jruby
drbobbeaty has joined #jruby
<headius[m]>
enebo: ok I have spent the last hour trying to get the GHA macOS image to build this successfully but it is still early days it seems
<headius[m]>
enebo: ok I have spent the last hour trying to get the GHA macOS image to build this successfully but it is still early days it seems
<headius[m]>
I am going to disable that build in CI since it is not critical to getting this released
<headius[m]>
I am going to disable that build in CI since it is not critical to getting this released
<enebo[m]>
MacOS for rust is not too bad
<enebo[m]>
MacOS for rust is not too bad
<enebo[m]>
The GHA actions stuff feels very wild west/Somalian
<enebo[m]>
The GHA actions stuff feels very wild west/Somalian
<headius[m]>
yeah the problem is getting the SDK with arm64 support wired up properly... nobody seems to have exactly the right incantation to make it work
<headius[m]>
yeah the problem is getting the SDK with arm64 support wired up properly... nobody seems to have exactly the right incantation to make it work
ur5us_ has joined #jruby
ur5us_ has joined #jruby
<enebo[m]>
Somalian in the sense of no functioning government
<enebo[m]>
Somalian in the sense of no functioning government
<headius[m]>
the official runner issue is unresolved and the suggested solution is "host it on your own M1 mac"
<headius[m]>
the official runner issue is unresolved and the suggested solution is "host it on your own M1 mac"
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
drbobbeaty has joined #jruby
<headius[m]>
enebo: I think this should wait until .18
<headius[m]>
enebo: I think this should wait until .18
<enebo[m]>
.18 or .19?
<enebo[m]>
.18 or .19?
<headius[m]>
now on jnr-ffi and it is like 99% passing but I have a few failures to look into
<headius[m]>
now on jnr-ffi and it is like 99% passing but I have a few failures to look into
<headius[m]>
wel, .17 is next
<headius[m]>
wel, .17 is next
<headius[m]>
so not in that
<headius[m]>
so not in that
<enebo[m]>
heh ok I keep thinking we put out .17
<enebo[m]>
heh ok I keep thinking we put out .17
<enebo[m]>
I had been wondering if you would come to this conclusion but mostly just due to libffi not even being released with the right changes yet
<enebo[m]>
I had been wondering if you would come to this conclusion but mostly just due to libffi not even being released with the right changes yet
<enebo[m]>
The fact there are more issues probably points out some teething which maybe does not yet belong on our maintenance branch
<enebo[m]>
The fact there are more issues probably points out some teething which maybe does not yet belong on our maintenance branch
<headius[m]>
possibly yes
<headius[m]>
possibly yes
<headius[m]>
the first issue I ran into with jnr-ffi was just that we needed type aliases in the right place, but they are the same aliases as on x86_64
<headius[m]>
the first issue I ran into with jnr-ffi was just that we needed type aliases in the right place, but they are the same aliases as on x86_64
<headius[m]>
but the next issue is three failures in varargs, and I thought I saw new commits today relating to libffi varargs
<headius[m]>
but the next issue is three failures in varargs, and I thought I saw new commits today relating to libffi varargs
<headius[m]>
so it is really close but still in progress
<headius[m]>
so it is really close but still in progress
<headius[m]>
everything else in jnr-ffi passed
<headius[m]>
everything else in jnr-ffi passed
<enebo[m]>
Just so I understand...This is part of some universal compilation where if something is written to arm64 it won't use the x86_64 emulation?
<enebo[m]>
Just so I understand...This is part of some universal compilation where if something is written to arm64 it won't use the x86_64 emulation?
<enebo[m]>
Or have people made M1 linux or something?
<enebo[m]>
Or have people made M1 linux or something?
<headius[m]>
I don't understand what you are asking
<headius[m]>
I don't understand what you are asking
<enebo[m]>
I thought M1 hardware still worked with x86_64 emulation in hardware
<enebo[m]>
I thought M1 hardware still worked with x86_64 emulation in hardware
<headius[m]>
this is to build an arm64 binary for jffi so it will work natively on M1
<headius[m]>
this is to build an arm64 binary for jffi so it will work natively on M1
<headius[m]>
darwin-arm64
<headius[m]>
darwin-arm64
<headius[m]>
we can run fully emulated x86_64 JDK and jffi but it will be slow of course
<headius[m]>
we can run fully emulated x86_64 JDK and jffi but it will be slow of course
<headius[m]>
or we can run native M1 JDK but then have no native support
<headius[m]>
or we can run native M1 JDK but then have no native support
<headius[m]>
so this fixes that
<headius[m]>
so this fixes that
<enebo[m]>
slower right? I thought the penalty was pretty small
<enebo[m]>
slower right? I thought the penalty was pretty small
<headius[m]>
heh well define small
<headius[m]>
heh well define small
<enebo[m]>
but you answered my question
<enebo[m]>
but you answered my question
<enebo[m]>
it is for something compiled as ARM64
<enebo[m]>
it is for something compiled as ARM64
<enebo[m]>
I don't even remember the overheads mentioned when it first came out I thought it was <10% and on the eval hardware
<enebo[m]>
I don't even remember the overheads mentioned when it first came out I thought it was <10% and on the eval hardware
<headius[m]>
for a darwin-aarch64 JDK
<headius[m]>
for a darwin-aarch64 JDK
<headius[m]>
I don't know what you mean by something compiled for arm64
<headius[m]>
I don't know what you mean by something compiled for arm64
<enebo[m]>
I mean not emulated x86_64 code
<enebo[m]>
I mean not emulated x86_64 code
<headius[m]>
ok
<headius[m]>
ok
<enebo[m]>
Compiled for the targetted native platform of arm64
<enebo[m]>
Compiled for the targetted native platform of arm64
<enebo[m]>
So you are saying it is like 10x slower
<enebo[m]>
So you are saying it is like 10x slower
<headius[m]>
for this case yeah, and visibly slow for anything else I have run but I have not timed other things
<headius[m]>
for this case yeah, and visibly slow for anything else I have run but I have not timed other things
<enebo[m]>
The mac heads definitely downplayed the overhead if this is universal
<enebo[m]>
The mac heads definitely downplayed the overhead if this is universal
<headius[m]>
in any case people will be grabbing native JDKs for M1 now since there are a few available, and then they will get bad compat from JRuby
<headius[m]>
in any case people will be grabbing native JDKs for M1 now since there are a few available, and then they will get bad compat from JRuby
<enebo[m]>
10x is totally unusable so I wonder how much this is openjdk doing lots of tricks which will not work well
<enebo[m]>
10x is totally unusable so I wonder how much this is openjdk doing lots of tricks which will not work well
<headius[m]>
yeah I would say they were blowing a ton of smoke
<headius[m]>
yeah I would say they were blowing a ton of smoke
<headius[m]>
and from what I have heard from users, this extends to apps... like Adobe freaks finding x86_64 Photoshop is unusable
<headius[m]>
and from what I have heard from users, this extends to apps... like Adobe freaks finding x86_64 Photoshop is unusable
<headius[m]>
I suspect this is why they were initially forbidding benchmarks... people would not be sure they were running M1 binaries and report Rosetta numbers
<headius[m]>
I suspect this is why they were initially forbidding benchmarks... people would not be sure they were running M1 binaries and report Rosetta numbers
<enebo[m]>
heh ok. It is perhaps people are looking at simple apps which display files or something which is UI driven and don't see any lag but once you get into a realm where you are doing lots of math etc it really exposes the overhead
<enebo[m]>
heh ok. It is perhaps people are looking at simple apps which display files or something which is UI driven and don't see any lag but once you get into a realm where you are doing lots of math etc it really exposes the overhead
<headius[m]>
oh I should clarify one thing... this is not M1, it is the last major iPad chip A12X or something
<headius[m]>
oh I should clarify one thing... this is not M1, it is the last major iPad chip A12X or something
<headius[m]>
so it is nearly M1 but not
<headius[m]>
so it is nearly M1 but not
<enebo[m]>
Or this is partially your kit
<enebo[m]>
Or this is partially your kit
<enebo[m]>
yeah
<enebo[m]>
yeah
ur5us_ has quit [Ping timeout: 260 seconds]
ur5us_ has quit [Ping timeout: 260 seconds]
<enebo[m]>
People said that at the time but I wondered if that was just wishful thinking or not
<enebo[m]>
People said that at the time but I wondered if that was just wishful thinking or not
<headius[m]>
maybe M1 does a lot better with Rosetta, I am not sure.. but I have heard a lot of anecdotes from people saying don't move unless you are sure all your stuff is native
<headius[m]>
maybe M1 does a lot better with Rosetta, I am not sure.. but I have heard a lot of anecdotes from people saying don't move unless you are sure all your stuff is native
<headius[m]>
really it is not surprising... CISC emulated on RISC has to take a hit
<headius[m]>
really it is not surprising... CISC emulated on RISC has to take a hit
<enebo[m]>
well anyways. It looks like this will happen sooner than later. Even if it was only 10% people would still be screaming for MAX PERFORMANCE
<enebo[m]>
well anyways. It looks like this will happen sooner than later. Even if it was only 10% people would still be screaming for MAX PERFORMANCE
<headius[m]>
they had the same issues with PPC on x86 20 years ago
<headius[m]>
they had the same issues with PPC on x86 20 years ago
ur5us_ has joined #jruby
ur5us_ has joined #jruby
<headius[m]>
we can get this released and in a 9.2 PR and then sic the dogs on it
<headius[m]>
we can get this released and in a 9.2 PR and then sic the dogs on it