Hi,
I have made good experience with Dibrom Lame Versions.
Is there a 3.95.1 Compile Version ?
Many Thx
Full Version: 3.95.1 Dibrom compile ?
AFAIK, Dibrom announced that he would not longer work on LAME a long time ago.
well... working on lame and compiling it aren't that similar
that said, i don't think he has (wants/needs/etc) to
john33 does a great job of compiling software for the windoze crowd
later
that said, i don't think he has (wants/needs/etc) to
john33 does a great job of compiling software for the windoze crowd
later
QUOTE (xmixahlx @ Feb 13 2004, 12:54 PM)
well... working on lame and compiling it aren't that similar
Nitpickers aren't we?
I think van Dusel's "intention" on his post was obvious: "are there going to be any Dibrom enhancements to the 3.95.1 version, as it was for the 3.90?"
Answer: It's very very unlikely.
QUOTE (AtaqueEG @ Feb 13 2004, 06:29 PM)
AFAIK, Dibrom announced that he would not longer work on LAME a long time ago.
This accords with my own recollection.
From 3.95.1 onwards, the switches that Dibrom used were dropped on the suggestion of Gabriel, particularly in the context that the tuning was being done on compiles that did not include them anyway.
QUOTE
From 3.95.1 onwards, the switches that Dibrom used were dropped
They are not dropped but used by default.
Sorry, I was referring to the option(s) that altered the rounding/truncation of float to int.
Edit: I must be going mad here!! Gabriel, I thought you requested the above, but I notice that all is as it was in the CVS project files!! Is my memory failing me?
I wouldn't be too surprised!!! 
Edit: I must be going mad here!! Gabriel, I thought you requested the above, but I notice that all is as it was in the CVS project files!! Is my memory failing me?
I wouldn't be too surprised!!!
The makefile in the cvs is featuring a wrong float->int convertion?
If so, please tell me which option to change.
If so, please tell me which option to change.
QUOTE (Gabriel @ Feb 14 2004, 09:54 AM)
The makefile in the cvs is featuring a wrong float->int convertion?
If so, please tell me which option to change.
If so, please tell me which option to change.
The ICL option I had in mind was '/Qrcd', but it seems my memory IS failing me as a check back through the LAME releases reveals it was removed way back!!!
So just ignore me!!
John,
any chance of getting a modified "Intel specific" ICL8 compiles that work on AMD CPUs in the future?
Ref: http://tinyurl.com/2pwpw
And btw, thanks for the excellent work so far!
Best regards,
halcyon
any chance of getting a modified "Intel specific" ICL8 compiles that work on AMD CPUs in the future?
Ref: http://tinyurl.com/2pwpw
And btw, thanks for the excellent work so far!
Best regards,
halcyon
QUOTE (Halcyon @ Feb 14 2004, 04:17 AM)
John,
any chance of getting a modified "Intel specific" ICL8 compiles that work on AMD CPUs in the future?
Ref: http://tinyurl.com/2pwpw
And btw, thanks for the excellent work so far!
Best regards,
halcyon
any chance of getting a modified "Intel specific" ICL8 compiles that work on AMD CPUs in the future?
Ref: http://tinyurl.com/2pwpw
And btw, thanks for the excellent work so far!
Best regards,
halcyon
it'll only work on A64s because the hack needs SSE2 support.
Intel is only checking for CPUID flags, not for existence of actual MMX/SSEx features.
-QxN flag compile has not yet generated ANY MMX/SSE/SSE2/SSE3 code. Should work on any Pentium class cpu.
Ref: http://tinyurl.com/2dow5
BTW, even after compile it shouldn't be too difficult to check the compile for MMX/SSE/SSE2/SSE3 content.
So, if it's otherwise possible, why not try?
Also, a P4/A64 specific compile (with the CPUID check removed) would probably be welcomed by quite a few as well.
And don't get me wrong, I'm quite happy with the compiles as they are. It's up to John (and other compilers) to decide if they can and have the time to improve on them even further.
-QxN flag compile has not yet generated ANY MMX/SSE/SSE2/SSE3 code. Should work on any Pentium class cpu.
QUOTE
I think that the particular optimization they are doing, at least for
this benchmark, does not involve any special trickery with the way
instructions work. It doesn't even rely on MMX/SSE/SSE2/SSE3, this
particular mcf optimization appears to be soley re-arranging fields in
a struct, which is clearly not intel-specific and any processor (intel
or amd) should be able to take advantage of this. It wouldn't surprise
me to learn of more cases like this one where it appears Intel is
trying to handicap AMD's performance on SPEC. It's possible that there
are programs that, when compiled with the -QxN flag, will generate
code that will not work on AMD processors but I've yet to encounter
one.
this benchmark, does not involve any special trickery with the way
instructions work. It doesn't even rely on MMX/SSE/SSE2/SSE3, this
particular mcf optimization appears to be soley re-arranging fields in
a struct, which is clearly not intel-specific and any processor (intel
or amd) should be able to take advantage of this. It wouldn't surprise
me to learn of more cases like this one where it appears Intel is
trying to handicap AMD's performance on SPEC. It's possible that there
are programs that, when compiled with the -QxN flag, will generate
code that will not work on AMD processors but I've yet to encounter
one.
Ref: http://tinyurl.com/2dow5
BTW, even after compile it shouldn't be too difficult to check the compile for MMX/SSE/SSE2/SSE3 content.
So, if it's otherwise possible, why not try?
Also, a P4/A64 specific compile (with the CPUID check removed) would probably be welcomed by quite a few as well.
And don't get me wrong, I'm quite happy with the compiles as they are. It's up to John (and other compilers) to decide if they can and have the time to improve on them even further.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.